1. Mehr Markup als Content
Tabellen-Layout oder andere veraltete Web-Techniken haben meist zur Folge, dass mehr Markup als Content im Quelltext zu finden sind. Das macht es den Suchmaschinen sehr schwer, die eigentliche Inhalte aufzufinden und zu bewerten. Markup im Sinne der Webstandards fällt meist schlank aus und macht eine Website zugänglich - auch für Suchmaschinen.
2. Über 30KB pro Seite
Meist resultiert dieses Merkmal aus dem erst-genannten. Falls es sich doch um soviel Content handeln sollte, wird es für Leser und Suchmaschine schwer, all die Informationen aufzunehmen. Da taucht wohl eine Schwäche von Weblogs auf: Ein großer Artikel mit 15 Kommentaren können schon eine ganze Menge an Content bilden.
3. "Spacer-GIF" in Such-Ergebnissen
Ein kläglicher Versuch, seine Tabellen- und Spacer GIF-verseuchten Seiten kurzfristig valid zu schreiben, kann zur Folge haben, dass die sinnlosen alternativen Texte für Bilder in Such-Ergenissen vorzufinden sind. Suchergebnisse mit unerwünschten Wörtern wie "header-image" oder "1px-spacer" sind da leider keine Seltenheit.
4. Kein Element ohne class oder inline-Style
Wenn selbst jedes normale p für reinen Text eine class erhält, ist irgendetwas beim Verständnis von CSS schiefgegangen. Verscheidene Selektoren (Child-Selektoren oder Vererbungen) ermöglichen das Einsparen von Klassivizierungen oder eindeutigen Identifizierungen. Inline-Styles sollten auch vermieden werden, da sie den Quelltext nur unübersichtlich, schwerfällig und eine spätere Wartung schwierig machen.
5. Eingebettetes JavaScript
Suchmaschinen werden irgendwann quängeln wenn sie jedesmal erst 10 KB Dokumentenköpfe mit eingebettetem JavaScript lesen müssen, bevor sie den richtigen Content zu Gesicht bekommen. Ausgelagertes JavaScript ist genauso sinnvoll wie ausgelagertes CSS.
Mach's besser
Beuge diesen Merkmalen und Problemen vor und halte dich an Tipps wie folgende. Die Suchmaschinen und die Besucher werden dir dankbar sein.
- Spare Markup und stelle den Inhalt in den Vordergrund
- Bleib fern von veralteten Layout-Methoden
- Lagere CSS und JavaScript aus
Danke für den Tipp. Ich hab letztens noch hier im Büro mit meinen Kollegen diskutiert, ob 30KB viel sind... Aber 1,2 MB sind ja wohl die Höhe schlechthin *g*
Jetzt stellt sich für mich die Frage, worauf sich diese 30 Kilobyte beziehen - auf die reine HTML-Seite oder auch alles was dazugehört?
Ein kurzes Document Size via Web Developer Toolbar hat mir für diese Seite 444 Kilobyte ausgespuckt - auch nicht gerade wenig.
Um dann das Thema vielleicht ein wenig auszuweiten (sozusagen "6 Merkmale von schlechten Websites"): Überdimensionierte Grafiken.
Jeriko, ich meine nur die einzelne Seite ohne Anhang. Also das was dir die Firefox-Seiteninformationen (Rechtklick > Seiteninformationen anzeigen) auspucken.
Na ja, 15 Kommentare machen in einem Weblog noch keine Probleme. Dieser Beitrag von mir hat z.B. 206 Kommentare und die Seite kommt (nach Deiner Methode) auf 177 kB. Das ist etwas über den Norm, aber auch ein Ausnahmefall. Bei Beiträgen mit einer normalen Anzahl an Kommentaren fällt das nicht ins Gewicht. (Wenn der Kommentierende nicht gerade einen 100-Seiten-Roman postet. :D )
Wie du schon sagst, ist das ein Ausnahme-Fall. Aber du wirst wohl keinen kennen, der sich diese Menge an Kommentaren durchliest. http://labuschin.com/?d=7&id=114 wird häufig besucht, die Kommentare sind zwar weitaus weniger, dafür aber meist länger. Da gehe ich auch nicht von aus, dass diese Seite komplett durchgelesen wird.
Ich denke, wenn wir von Weblogs reden, dürfte jedem klar sein, dass diese viele Informationen enthalten. Eine "einfache" Website, die z.B. eine Firma vorstellt oder Bilder des letzten Urlaubs anzeigt, sollte diese Größe nicht überschreiten.
Nur wie erstellt ein Neuling solche guten HTML-Dateien, wenn er auf Software zurückgreifen will/muss, die ihm alles so einfach wie möglich machen soll? Und woher soll er wissen, dass die Software Müll produziert? Ich bin an meinem Bekannten gescheitert, da er nicht davon abrücken wollte, sie zu benutzen, obwohl er das Problem erkannte. Die Arbeit liegt nicht nur beim Anwender/HTML-Bastler sondern auch bei den Entwicklern der Software.
Stimmt. Und wie man aktuell sieht ( Kein Windows live-Shopping mit Firefox ) hat MIcrosoft nicht in der HTML-Entwicklung zu suchen :)
Es würde mich allerdings auch nicht wundern, wenn es nur an dem Aufruf des XMLHTTPRequest Objekts liegen würde ;-)
Da gehe ich auch nicht von aus, dass diese Seite
komplett durchgelesen wird.
Das stimmt wohl. Ich lese zwar manchmal auch die
Kommentare zu einem Artikel komplett durch, aber im
Regelfall liest man maximal die Kommentare die zu
einer aktuelen Diskussion gehören.
Eine Alternative bei wäre, entweder ältere
Kommentare nur durch User-Interaktion (Button o.ä.)
aufzurufen oder zumindest eine seitenweise
Darstellung mit 10-20 Kommentaren pro Seite. Ich
überleg grad, ob das z.B. mit WordPress zu machen
ist (wahrscheinlich schon).
Die Arbeit liegt nicht nur beim Anwender/HTML-Bastler sondern auch bei den Entwicklern der Software.
Absolut richtig. Das sollte der erste Ansatzpunkt für ein schlankeres, semantischeres, besseres Web sein. Denn prozentual gesehen ist der "coder-by-hand" eher die Ausnahme und solange selbst Anwendungen wie Dreamweaver & Co. keine sauberes MarkUp liefern (solche Programme nutzen ja selbst professionelle Webdesigner zuhauf), so lange wird der Weg dorthin sehr steinig sein.
John, für das was du vorhast gibts in der Tat schon als Plugin, z.B. bei http://www.keyvan.net/code/paged-comments/
Für threaded comments habe ich noch keinen Lösung gefunden, halte ich aber auch nicht für sehr sinnvoll.
Ich dachte es mir (für WordPress gibt es ja auch eher zu viel als zu wenig Plugins ;-) ) bzw. hatte schon mal was darüber gelesen.
Ist sicher einen Blick wert, auch wenn Artikel mit Kommentaren 30+x wirklich eher selten sind und alles was darunter ist, lädt eigentlich auch noch ganz flüssig.
Danke Jeriko.
Hi,
echt gut zusammengefasst :) Lediglich in einem Punkt bin ich nicht so 100%ig Deiner Meinung. Und zwar, was die Verwendung von Klassen im Markup angeht. Nicht die Menge machts hier, sondern die Art/der Verwendungszweck der Klassen. Eigentlich ist es ganz logisch. Laut w3c kommt Inhalt und Bedeutung ins html, das Aussehen ins css. Klassennamen stehen im html. Klassennamen sollten also logischerweise nicht das Aussehen, sondern die Bedeutung transportieren. Häufig führt das tatsächlich zu einer Verschlankung der Klassenverwendung. Es kann aber auch zu zusätzlichen Klassen führen. Es kann durchaus vorkommen und sinnvoll sein, bestimmten Elementen eine Klasse oder auch eine ID zuzuweisen, die die Bedeutung dieses Elements genauer spezifiziert, ganz ohne daß sich diese Klasse oder diese ID auch nur im Geringsten im css wiederfindet, also ganz ohne daß an diese Bedeutung auch ein besonderes Aussehen gekoppelt ist.
Also generell ist da an dem von Dir genannten Punkt schon eine Menge dran. Aber da Webdesigner wie andere Menschen auch dazu neigen, das Kind mit dem Bade auszuschütten, und bevor jetzt Klassenvermeidung auf Teufel komm raus betrieben wird, relativiere ich das lieber mal.
Nadja
07.05.2006
Ich musste beim Punkt "30KB pro Seite" lachen, da ein Bekannter mich neulich fragte, ob seine Webseite so okay sei. An sich hatte ich an Navigation, Design, etc. nichts auszusetzen, bis ich die Größe der Datei sah: 1,3 MB für eine HTML-Datei, die vollgepfropft war mit unnötigen Styleangaben, eingebettetem JavaScript und proprietärem Markup - er hatte sie mit MS Publisher erstellt.
Guter Text, vielleicht könntest du am Ende noch einmal eine Übersicht mit allen Tips geben.