Kann man abhaken
Checkliste: Sauberes und performantes Frontend
Checklisten sind eine feine Sache. Ich benutze sie gerne, um den Überblick zu behalten und hinterher mich nicht darüber ärgern zu müssen, dieses oder jenes mal wieder außer Acht gelassen zu haben. Jedenfalls idealerweise. Wer nach Webstandards und mit einem entsprechenden Anspruch an Ordentlichkeit, Performanz und Zugänglichkeit Webseiten entwickelt, achtet auf zig Dinge gleichzeitig. Und im besten Fall kommt kurz vor dem Launch hinter jedes dieser Dinge ein “bedacht und erledigt”-Häkchen. Check.
Spielerei am Rande: Mit Klick auf die Listenelemente kann man dieses Thema virtuell abhaken.
Grundsätzliches
- Valides HTML, saubere Semantik
Das (eigentlich die) HTML sollte dem Validator stand halten, aber wichtiger ist noch der korrekte Einsatz der Elemente und die Trennung von Inhalt, Präsentation und Verhalten. Webstandards und guter Stil sind große Themen, aber eine wichtige Grundvoraussetzung. - Screen- und Printstylesheet
Gerade letzteres wird im Eifer des Gefechts ganz gerne mal übersehen. Dabei nimmt es eigentlich kaum Zeit in Anspruch. Grundlagen bietet Jens Meierts Artikel. - Stylesheets für weitere Darstellungen (Tablets, Smartphones,…)
Im Zuge von Responsive Webdesign und allgemeiner Optimierung für mobile Endgeräte bietet sich – je nach Anforderung des Projekts – beispielsweise der Einsatz von Media Queries und entsprechender Stylesheets an. - Validierung des CSS und Verifizierung des JavaScripts
Naja gut, es GIBT einen CSS-Validator, aber durch Hacks, Vendor-Prefixes und vieles mehr spuckt der ohnehin nur Fehler aus. Ist also eher Theorie. Für (selbstredend Unobstrusive) JavaScript ist JSLint ein gutes Kontrolltool. Bei intensivem Einsatz von JS empfiehlt sich aufgrund der geringeren Fehleranfälligkeit in Sachen Crossbrowser der Einsatz eines Frameworks wie jQuery. - Einsatz von HTML5-Elementen
…bei entsprechendem Doctype. Für alle Microsoft-Browser kleiner als IE9 macht es Sinn, die Elemente noch einmal per JS zu erläutern und in jedem Fall sollten einige Elemente im Stylesheet auf display:block geeicht werden. Templates wie HTML5 Boilerplate schaffen diese und mehr Voraussetzungen für den Einsatz von HTML5.
Fallbacks
- JavaScript
Die Seite sollte auch ohne JavaScript noch intakt bleiben und funktionieren. Auch wenn Google und Apple das mittlerweile anders sehen. Stichworte Progressive Enhancement bzw. Graceful Degradation. - CSS
Das Layout sollte nicht direkt explodieren, wenn bestimmte CSS-Eigenschaften nicht unterstützt werden. Werden böse dunkle Hacks verwendet sollten diese nicht aus Versehen Browser(generationen) beeinflussen, für die sie gar nicht gedacht waren. Auch ein Blick auf die Seite komplett ohne CSS kann Beurteilungen zur Qualität des Markups erleichtern. - PHP
Nicht direkt eine Aufgabe des Frontend-Entwicklers, aber wenn ein Script mal Fehler ausspuckt, sollten diese einigermaßen sinnvoll formuliert und platziert sein. Gibt kaum was schöneres als “mySQL-Statement is invalid…” irgendwo überhalb des bodys.
Usability / SEO
- Weiterleitungen einrichten
Häufig ändern sich bei Relaunches Website-Strukturen und alte URLs gelten nicht mehr. Für Google und für Besucher ist daher darauf zu achten, dass diese alten Adressen auf die entsprechenden neuen weitergeleitet werden. - Sprechende URLs durch ModRewrite
Hübsch für Suchmaschinen und Menschen: Verständliche und lesbare URLs, auch in tiefen Ebenen. - Microformats
Auf dem Weg zum semantischen Web können diese kleinen Anreicherungen für eine bestimmte Nutzergruppe echte Anwendungsverbesserungen bedeuten. Sofern (Such)Maschinen diese erweiterte Semantik auslesen, gibt es da natürlich auch Vorteile. Alternative Techniken sind RDFa und natürlich die neuen HTML5-Microdata-Spezifikationen. Bislang erfahren nach meinem Stand die erstgenannten Microformats allerdings die meiste Anwendung. - Brauchbare <head>-Elemente: <title>
Ein guter Seitentitel hilft Nutzern und Suchmaschinen. Jede (Unter)Seite sollte einen sinnvollen, individuellen Titel bekommen, das Wichtigste zuerst genannt werden und noch so vieles mehr ist zu beachten. - Brauchbare Metatags: description
Auch hier macht es Sinn, jeder Seite einen sinnvollen Text zu verpassen sowie Verständlichkeit und Keywords entsprechend zu berücksichtigen – schon alleine, weil dieser Text bei den meisten Suchmaschinen als Kurzbeschreibung des Ergebnisses verwendet wird. - GEO-Tags
Wieder einmal zur maschinenlesbaren Kategorisierung der Inhalte gut zu gebrauchen. Sie ordnen die Website geographisch ein. Macht bei Angeboten mit Standortbezug durchaus Sinn. - robots.txt
Zwar bin ich bisher ganz gut ohne diese Datei ausgekommen, aber es hält sich die Annahme, diese Datei sei nicht ganz unwesentlich. Vermutlich ist da was dran. - Weitere sinnvolle Meta-Tags
Es gibt noch zahlreiche weitere Metatags, welche davon sinnvoll sind, sollte jeder selbst entscheiden oder vom SEOler entscheiden lassen. - Metatag robots
Was in der Entwicklungsphase häufig auf “noindex,nofollow” gesetzt ist, sollte beim Launch dann geändert werden. Nur so als Erinnerung. - XML-Sitemap anlegen
Für Redaktionssysteme gibt es dafür Automationen (z.B. das Plugin für WordPress), bei statischen Seiten hilft der Sitemap Generator weiter.
Zugänglichkeit / Barrierearmut
- alt- und title-Attribute
Sie gehören dazu. Während alt für Bilder sinnvoll und verpflichtend ist, erzeugen title-Attribute zusätzliche Informationen, die moderne Browser als Tooltip beim hover-Zustand darstellen – Elementen wie und brauchen das title-Attribut zwingend. - Verhalten bei Schriftgrößenänderung
Wie reagiert das Layout, wenn die Schriftgröße von Client angepasst wird? Passt es sich an, lassen sich alle Elemente sauber vergrößern oder explodiert es nach einer Zoomstufe direkt? Auch bei fixen Layouts ist die Angabe der Dimensionen in Prozent und em (respektive ex) sinnvoll. - Verhalten bei Viewport-Änderung
Insbesondere bei flexiblen Layouts immer wieder mehrere Tests wert. - Darstellung ohne CSS, Darstellung/Funktionen ohne JavaScript
Bleibt die Seite verständlich und navigierbar, wenn alle Layout-Informationen fehlen? Sind Funktionen gewährleistet, auch wenn das JavaScript versagt? - Darstellung ohne (Hintergrund)Bilder
Sollte es dem Server mal nicht gelingen, die großkalibrigen Bilder auszuliefern, kann das eine Seite schon mal unbrauchbar machen. So etwa bei weniger eleganten Image-Replace Lösungen oder Schriftfarben, die auf ein dunkles Hintergrundbild angewiesen sind. Testen lässt sich das gut mit der Web Developer Toolbar. - Darstellung bei hohem und niedrigen Kontrast und ohne Farben
Da wir niemals sicher gehen können, dass unser hübsches Design auch genau so knallig und sauber dargestellt wird wie aus unserem Bildschirm, sollten wir einige Extreme testen. Sei es, weil sehbehinderte Menschen den Kontrast hochdrehen (oder teilweise Farben umkehren) oder weil manchen Geräten die entsprechende Helligkeit und anderes fehlt. - Tastaturnavigation: :focus und Skiplinks
Bei jeder :hover-Deklaration sollte auch ein :focus stehen. Auch die Outlines aktiv zu lassen, ist sinnvoll, wenn die gestalteten hover-Zustände ohne Mauszeiger schwierig auszumachen sind. Skiplinks helfen Tastaturnutzern, schneller zum gewünschten Bereich auf einer Seite zu gelangen. - Funktionieren alle Ankerpunkte?
Zum Beispiel für oben genannte Skiplinks. Testen, testen, testen. - Ist die Tabulatorreihenfolge in Ordnung?
Bei hierarchisch sauber geschriebenem Code ist das meist kein Thema, bei Formularen oder seltsamen SEO-Tricks (wie den Header nach dem Content coden und per CSS nach oben positionieren) kann sowas schon mal zum Fallstrick werden.
Performance
- Overhead reduzieren
Gerade bei Verwendung von HTML/CSS-Frameworks: ungenutzte Klassen rausschmeißen. Inwieweit Tools wie HTMLTidy noch aufräumen können, hängt vom Coding ab. Automatische CSS-Aufräumtools gibt’s zwar auch, aber das ruft auch direkt Probleme mit der Kaskade und mit Hacks auf den Plan. Weiterhin gilt: CSS-Selektoren nicht unnötig in die Länge ziehen und -Deklarationen zum Beispiel mit Shorthands schlank halten - Bildkomprimierung
Was Photoshop schon gut kann, kann Fireworks noch besser, können Tools wie RIOT, Smushit, PunyPNG am allerbesten: Bilder komprimieren. - Sprites, wo es geht
Die Summe lädt schneller als ihre Einzelteile nacheinander: CSS-Sprites - Styles auslagern
Damit gecached werden kann. Klar, oder? - JavaScript in den Fuss
Damit die Seite nicht erst auf das JS warten muss, bis sie weiterlädt. Script-Elemente kurz vor den
Sehr schöne Liste! Ich frage mich zur Zeit nur, wie du das mit der Testumgebung handhabst? Siehst du zu das du eine Testumgebung aufbaust, welche dem Livesystem gleicht oder entwickelst du in einem Unterverzeichnis im Livesystem?
Ich wechsle ab einem bestimmten Entwicklungsstand vom lokalen System rüber zum entsprechenden Server, meist unter Benutzung einer Subdomain, weil die eigentliche URL ja noch das ausliefern soll, was bisher war. Die Subdomain (die nur ich kenne und idealerweise passwortgeschützt ist) zeigt dann einfach auf ein anderes Verzeichnis auf dem Server. Bei Einsatz eines CMS müssen bei der Liveschaltung dann i.d.R. natürlich ein paar Pfade angepasst werden.