16.2    Code-Feintuning 

Guter Code ist optimierter Code. Er wird entsprechend seiner Bedeutung eingesetzt und enthält keine überflüssigen Angaben.

 

16.2.1    Responsibility 

Zu einem aufgeklärten Menschen gehört ein verantwortungsvoller Umgang mit den Ressourcen der Erde. Zu einem guten Webdesigner gehört auch ein verantwortungsvoller Umgang mit den (Web)ressourcen. Unübersichtlicher und überflüssiger Code verschwenden genau diese Ressource an Zeit (und damit Geld) und Performance der Webseite (und damit auch wieder Zeit und Geld).

 

16.2.2    Performance 

Je schneller eine Webseite lädt, desto besser die Benutzerfreundlichkeit, desto mehr Besucher, desto mehr Umsatz und desto weniger Betriebskosten. Jeder kennt dieses nervige Gefühl, auf eine ladende Webseite zu warten. Jede Sekunde ist zu viel. Verschiedene Studien haben sich mit der Wartezeit/Ladezeit beschäftigt. Länger als drei, höchstens vier Sekunden sollte eine Seite nicht laden. Als Webseitenbetreiber gibt es Einflussfaktoren, die man nicht oder nur bedingt beeinflussen kann, wie z. B. die Serverleistung und die Datenverbindung. Aber man kann einiges dafür tun, dass das Datenvolumen der Seite möglichst gering ist. Klar, eine Seite, die viele großformatige Bilder benötigt, wird mehr Daten beanspruchen als eine minimalistische, eher typografische Seite.

Abbildung 16.8    Knapp die Hälfte der Nutzer wartet beim Surfen mit dem Smartphone nicht länger als vier Sekunden auf eine Webseite (de.statista.com/statistik/daten/studie/202650/umfrage/wartezeit-bis-zum-verlassen-einer-mobilen-website/.

Um die Ladezeiten gering zu halten, sollten die eingesetzten Dateien weitestgehend möglichst klein sein. Abbildung 16.9 zeigt die Verteilung der Anfragen an den Server und die Datenmengen für einzelne Datentypen anhand der Beispielwebseite rheinwerk-verlag.de an.

Abbildung 16.9    Ein Performance-Test mit webpagetest.org zeigt unter anderem die Verteilung der Anfragen an den Server (Requests) und die Datenmengen an, wie hier für die Webseite rheinwerk-verlag.de.

Das Diagramm steht exemplarisch für viele andere Seiten, denn den Großteil der Anfragen und des Datenumfangs benötigen die Bilder und die JavaScript-Dateien. Einen eher geringen Umfang haben die Websprachen CSS und HTML. Bei einer Optimierung sollten also zuerst die Bilddateien betrachtet werden. Dies fängt mit der Auswahl des richtigen Bildformats an (siehe Abschnitt 11.10, »Bildformate«). Wo es geht, sollte auch auf Bilder verzichtet werden. Das bedeutet nicht, möglichst gar keine Bilder in seinen Designs zu benutzen, sondern Sie sollten eher die Möglichkeiten von CSS3-Effekten (Schatten, Verläufe usw.), SVGs und Icon-Fonts gezielt einsetzen. Es gibt verschiedene Tools, um den Datenbedarf von Bildern auch nach dem Abspeichern aus Photoshop (oder anderen Grafikprogrammen) noch weiter zu verkleinern. In Kapitel 11, »Bilder und Grafiken«, stelle ich Ihnen einige davon vor.

Um den zweiten großen Datenverursacher, die JavaScript-Dateien, zu optimieren, gilt es, besonders darauf zu achten, ob JavaScript wirklich nötig ist. Oft genug wird es für mehr oder weniger nette Animationseffekte eingesetzt. Der so beliebte Header-Slider (siehe Kapitel 14, »Animationen«) ist dafür ein gutes Beispiel. Sein Mehrwert hält sich häufig in Grenzen, die benötigten Skripte und Bilder verursachen aber eine enorme Datenübertragung. Mit dem Ergebnis, dass der Nutzer lange warten muss, um Inhalte (den Slider) angezeigt zu bekommen, die er gar nicht sehen will.

Also überprüfen Sie nicht nur jedes Skript frühzeitig auf seine Notwendigkeit (das beginnt schon bei der Konzeption und dem Design), sondern checken Sie auch auf jeder einzelnen Seite, ob hier wirklich alle Skripte notwendig sind. Ein Slider-Skript, das nur für die Startseite benötigt wird, muss nicht auf allen anderen Seiten mitgeladen werden. Bei der Einbindung z. B. mehrerer jQuery-Plug-in-Skripte passiert es schnell, dass auch jQuery mehrmals eingebunden wird, was aber unnötig ist und eben auch nur doppelte Daten lädt. Zu oft wird auch jQuery eingesetzt und geladen, wo sich Effekte mit ein paar Zeilen JavaScript umsetzen ließen.

JavaScript-Dateien selbst lassen sich oft auch noch optimieren, etwa durch eine Minimierung des Quellcodes. Dieser wird komprimiert, das heißt, alle Kommentare werden entfernt und die eigentlichen Funktionen kompakt hintereinandergeschrieben, dies spart zumindest einige wenige Bytes an Daten. Aber Achtung: Die Original-JavaScript-Datei sollten Sie für eventuelle spätere Änderungen besser auch behalten.

Abbildung 16.10    Oben das Original-JavaScript und unten die komprimierte Variante, erstellt mit dem Tool jscompress.com

Es gibt verschiedene Tools, die das Komprimieren von Quellcode ermöglichen. Dazu gehören z. B. jscompress.com und floern.com/tools/codecompressor, der auch HTML- und CSS-Dateien komprimieren kann.

Zusammenfassend und ergänzend hier noch ein paar Tipps zur Performance-Optimierung:

• Wählen Sie das richtige Bildformat.

• Setzen Sie CSS-Sprites ein.

• Reduzieren Sie Bildgrößen (mit entsprechenden Tools).

• Geben Sie Breite und Höhe der Bilder in HTML an.

• Reduzieren Sie HTTP-Requests: Fassen Sie CSS- und JavaScript-Dateien, wo möglich, zusammen.

• Optimieren Sie den Quellcode (mit entsprechenden Tools).

• Setzen Sie besser externe CSS- und JavaScript-Dateien ein, als Inline-CSS bzw. Inline-JavaScript zu verwenden.

• Laden Sie CSS im Header und JavaScript im Footer (damit das CSS vor dem Ausführen der JavaScript-Dateien geladen ist).

• Prüfen Sie Bilder und vor allem auch Skripte von Anfang an auf ihre Notwendigkeit.

• Der Einsatz von vorgefertigten Themes ist gut überzudenken. Diese bieten zwar jede Menge schöner Funktionalitäten, verursachen aber auch jede Menge Datenmengen/Ladezeit.

Welche Optimierungsmöglichkeiten Sie im Einzelfall einsetzen, hängt sicherlich auch von dem Aufwand und dem zu erwartenden Performance-Gewinn ab. Es gibt noch einige hilfreiche Tools, mit denen sich Webseiten überprüfen lassen und die Ihnen nützliche Anregungen liefern können:

Das Google Pagespeed Tool (developers.google.com/speed/pagespeed/insights) ist sehr bekannt und beliebt, das Ergebnis in Form von Prozentpunkten aber eher irritierend und durch das farbige Ampelsystem stark vereinfachend. Nicht jede »rote« Webseite (wie in Abbildung 16.11 die rheinwerk-verlag.de-Webseite) ist deswegen gleich schlecht umgesetzt. Hilfreicher sind hier schon eher die Anmerkungen, bei welchen »Problemen« eine Behebung hilfreich sein kann. Für die eigene Kontrolle ist das Tool okay, aber Kunden würde ich eher abraten, ihre Seite damit zu kontrollieren/testen. Die »Gefahr«, nach der Punktzahl zu urteilen, ist zu schnell gegeben.

Hilfreicher ist da schon der Pingdom Website Speed Test (tools.pingdom.com). Dieses vergibt zwar auch eine Punktzahl (nach welchen Kriterien hier auch immer), aber vor allem erhält man konkrete Daten zu interessanten Messwerten wie die Ladezeit, die Seitengröße (Datenmenge) und die Anzahl der Anfragen an den Server (Requests). Im Idealfall lädt die Seite schnell, die Datenmenge ist klein, und die Serveranfragen sind gering. Der Test liefert auch noch viele weitere Detailauswertungen, wie beispielsweise das Ladeverhalten einzelner Dateien. Aus diesen Werten lässt sich dann gut möglicher Optimierungsbedarf erkennen.

Als drittes Tool empfehle ich noch den webpagetest.org. Auch hier bekommt man eine umfangreiche Auswertung. Es kann sich auch lohnen, die letzten beiden Tests mehrmals und zu verschiedenen Zeiten durchzuführen, um eindeutige Ergebnisse zu bekommen.

Abbildung 16.11    Die Webseite rheinwerk-verlag.de – mit zwei Tools getestet, die unterschiedliche Ergebnisse lieferten, developers.google.com/speed/pagespeed/insights und tools.pingdom.com

 

16.2.3    Testen und Debuggen 

»That worked perfectly when I developed it.« Wenn alles nichts mehr hilft, bietet diese Seite Lösungen: programmerexcuses.com.

Zu den Aufgaben eines Webdesigners gehört das regelmäßige Testen der Seite auf verschiedenen Endgeräten und Browsern. Ziel ist es nicht, dass die Webseite in allen Browsern exakt gleich aussieht, sondern dass sie in allen Browsern gut bedienbar ist und ein gutes Nutzungserlebnis liefert. Das Debuggen, also das Finden und Korrigieren von Fehlern, gehört selten zu den angenehmen Aufgaben, aber es muss sein, um keine Nutzer unnötig zu vergraulen oder gar zu verlieren.

Erste Anlaufstelle für die Kontrolle des eigenen Codes sind die W3C-Validatoren validator.w3.org und jigsaw.w3.org/css-validator. Einige Browser bieten auch schon von Hause aus Entwickler-Tools an, mit denen sich einiges über die einzelnen Elemente der Webseite herausfinden lässt. Als zusätzliche Tools empfehlen sich vor allem der Firebug (getfirebug.com) und die Web Developer Toolbar (chrispederick.com/work/web-developer).

Abbildung 16.12    Die Entwickler-Tools im Chrome bieten vielfältige Optionen, um seine Seite und den Code zu testen.

Sowohl Firefox als auch Chrome verfügen inzwischen über On-Board-Mittel, um Seiten auf ihr responsives Verhalten zu testen.

In Firefox gehen Sie dazu über das Menü Extras • Web-Entwickler • Bildschirmgrössen testen.

In Chrome wählen Sie Anzeigen • Entwickler • Entwicklertools und klicken dann auf das kleine Smartphone-Icon Toggle Device Mode.

Um Seiten in unterschiedlichen Browsern und Browserversionen zu testen, bieten sich browsershots.org und browserstack.com/screenshots an. Bei opendevicelab.com finden sich Locations, die unterschiedliche Endgeräte zum Test bereitstellen. Mit wave.webaim.org lässt sich die Accessibility überprüfen. Und zum Testen der Responsivität eignen sich browserstack.com/responsive, mattkersley.com/responsive oder quirktools.com/screenfly.

Abbildung 16.13    Eine hilfreiche Checkliste für alle möglichen Development-Fragestellungen bietet webdevchecklist.com.