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.

Checkliste: Sauberes und performantes Frontend

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,...)
    Responsive Design, anyone? Na hoffentlich. Im besten Fall auch bitte mobile first. Media Queries Beispielseiten
  • 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 Browserhacks 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.
  • Client- und Serverfehler
    Sollt ein Script mal Fehler ausspucken, sollten diese einigermaßen sinnvoll formuliert und platziert sein. Am besten in Logfiles. Gibt kaum was Schöneres als „mySQL-Statement is invalid...“ irgendwo überhalb des bodys. Oder als Dialogbox mit kryptischen Fehlerhinweisen. Bedenke: das UI ist kein guter Ort für Fehlerausgabe, die für Entwickler bestimmt ist. Also reduzierte auch das console.log.

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.
  • Open Graph für das Crawling der Seite
    Mit Metatags wie og:title oder og:description hinterlegt man Informationen für das Open Graph-Protokoll, das von Facebook, Google Plus und wer weiß von sonst noch wem ausgelesen wird, um Auszüge, Vorschauen etc. zu erstellen. Verwandt damit auch sind die sog. Twitter-Cards.
  • 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. UPDATE: Das t3n veröffentlichte kürzlich auch eine schöne Zusammenfassung zum Thema robots.txt.
  • 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 - mittlerweile nicht nur für PNGs und JPGs sondern selbstredend auch für SVGs machbar und sinnvoll.
  • Styles auslagern
    Damit gecached werden kann. Klar, oder?
  • Critical CSS
    Styles, die für Elemente über dem Fold verantwortlich sind, können direkt inline notiert werden. Die Seite lädt dadurch subjektiv schneller, da der erste Teil der Seite nicht auf das Laden und Parsen externer Dateien angewiesen ist.
  • JavaScript in den Fuß
    Damit die Seite nicht erst auf das JS warten muss, bis sie weiterlädt. Script-Elemente kurz vor den-tag.
  • Bibliotheken aus Repositories laden
    HTTP-Requests an die eigene Domain lassen sich sparen, wenn global verwendete Elemente wie JavaScript-Bibliotheken aus den öffentlichen Repositories geladen werden. So schnell wie Google liefert ohnehin niemand. Außerdem sind viel verwendete Libs wie jQuery u.U. bereits durch andere Webseitenbesuche bereits im Cache des Nutzers.
  • HTTP-Requests und Datenmengen verringern
    Hierfür gibt's gleich mehrere Ansätze für verschiedene Bereiche: head.js fasst wunderbar JavaScript-Aufrufe zusammen und simplifiziert den Einsatz, minify stampft CSS und JS zu je einer Datei zusammen ohne die Quelldateien unbrauchbar zu machen und über die Auslagerung von Datenmengen (zum Beispiel Bildern) auf Subdomains oder gleich in die Cloud (beispielsweise Amazon S3) sollte man sich Gedanken gemacht haben.
  • Komprimierte Auslieferung der Dateien
    Serverseitig können Dateien komprimiert und vom Client nach Erhalt wieder entpackt werden. Einträge im der .htaccess mit dem Modul mod_deflate erzeugen entsprechende Bandbreitensparmaßnahmen. Update: Apache kann auch mod_gzip.
  • Expire Headers
    Das Festlegen von maximalen Gültigkeitszeiten nutzt bewusst den Cache und reduziert so Requests, um die Performance zu erhöhen. Auch eine Server-seitige Einstellung.
  • ETag
    Wer Cache sagt, muss auch ETag sagen. Über die Hintergrunde zur Kontrolle von Aktualisierungen und Cache-Verhalten.

Tools / Infrastruktur fürs Monitoring

  • Analyse
    Kostenlos und sehr gut machen das Google Analytics (an den Impressums-Text denken) oder Piwik. Als kostenpflichtiges Konkurrenztool gilt Mint.
  • Google Webmaster Tools
    Wenn gewünscht oder sinnvoll, kann man hier Google die Seite etwas näher bringen und Voraussetzungen für den Einsatz weitere Google-Produkte wie Adwords oder Products schaffen. Ich bilde mir auch ein, dass die Indizierung neuer Seiten dadurch schneller von statten geht. Vermutlich stimmt das nicht.

Cross-Browser-Testing

  • Internet Explorer
    Es muss ja leider sein. Hilfsmittel sind hier Multiple IE, IETester, die IE Developer Toolbar und das Firebug Lite-Bookmarklet. Mac-Nutzer testen die IEs in ihrer Virtuellen Maschine (Parallels oder Fusion) oder auf einer Bootcamp-Installation.
  • Moderne Browser
    Wer auf Firefox entwickelt, sollte auch die Webkit- (Chrome, Safari) sowie Presto- (Opera) engine testen und umgekehrt. Gerade bei CSS3-Einsätzen wird der ein oder andere Prefix schon mal vergessen. Und es soll sogar Bugs in modernen Browsern gegeben haben.
  • Mobile Browser
    Lassen wir hier WAP mal außer Acht, sind die verbreitetsten mobilen Browser wohl der iOS Safari, ein weiterer Webkit auf den Androids und und vielleicht, auf spukigen Geräten, noch der IE irgendwas sowie Opera Mobile. So wirklich ohne echtes Endgerät zuverlässig zu testen ist schwierig, SDKs mit Device-Simulatoren gibts für Apple und Andriod, und der Opera Mobile Emulator ist das, wonach er klingt.

Backe, backe, Häusle baue

Diese Liste wuchs in den letzten Monaten in meinen Notizen stetig und wurde immer wieder durch neue Impulse angereichert und verfeinert. Vollständig oder der Weisheit letzter Schluss ist sie deswegen noch lange nicht. Damit sie jetzt und in Zukunft vielleicht ein gutes Kontrollinstrument abgeben kann, lade ich dazu ein, Anregungen, Kritik und Erweiterungen in den Kommentaren anzubringen.