In dem letzten Teil meiner WPO Serie möchte ich mich der Clientseite zuwenden. Aktuell schauen wir zwar nur auf Browser, doch ich denke in Zukunft werden auch Apps von ähnlichen Optimierungen profitieren, sind doch manche sogar schon in HTML geschrieben.
Ein interessanter Aspekt von Browseroptimierung ist, dass es auf Annahmen basiert. Das ist eine nette Parallele zu SEO, welches fast ausschließlich auf Experimenten basiert, da niemand so recht weiß wie die Suchmaschinen bewerten. Deswegen nennen die meisten WPO Tools ihre Einschätzungen „Grade“ (Note). Genau wie in der Schule wissen wir nicht genau wie wir besser werden können, oder ob man noch deutlich besser als „sehr gut“ werden kann. Wir können nur versuchen uns zu verbessern. Dennoch gibt es ganz hilfreiche Werkzeuge, welche uns helfen können eine aktuelle Bewertung zu ermitteln und Ideen zur Verbesserung zu erhalten. Zwei Beispiele sind YSlow von Yahoo und PageSpeed von Google, welche beide einen Katalog von Best-Practices verwenden, um Webseiten zu überprüfen.
Alternativ kann man auch einen Aggregator wie webpagetest.org oder showslow.org verwenden, um verschiedene Tests ausführen zu lassen. Alle Werkzeuge bieten aber am Ende immer eine Art Checkliste mit Best-Practices und unser Abschneiden. Leider erhält man keine wirkliche Empfehlung wo man mit dem größten Effekt einfach optimieren kann.
Requests verschwenden Zeit
Abgesehen davon, dass wir nicht genau wissen wie sich das Antwortzeitverhalten einer Seite nach Anwendung von Best-Practices verbessern wird ist eines klar, unnötige Serveranfragen müssen vermieden werden. Sie kosten Zeit und Geld. Schauen wir uns die zwei Hauptbestandteile mal an:
- Verbindungsaufbau
- Datenübertragung
Natürlich kommt eine Datenübertragung nie ohne einen Verbindungsaufbau zustande. Die Datenübertragung kann im Wesentlichen mit zwei Mitteln eingedämmt werden.
- Komprimierung
- Caching
Komprimierung
Komprimierung ist leider oft vernachlässigt, obwohl sie einfach einzustellen ist. Dieser Umstand ist frühen Versionen des Internet Explorers geschuldet und eigentlich heute nicht mehr relevant. Die Komprimierung sollte nicht selbst programmiert werden, sondern dem Container überlassen werden. Den Apache konfiguriert man zum Beispiel so:
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css
text/javascript application/x-javascript application/javascript
application/json application/xml text/x-component
</IfModule>
Natürlich ist es auch sinnvoll seine Bilder zu komprimieren. Vor ein paar Tagen hat Kornel Lesinski ein nettes Tutorial über PNGs die funktionieren (englisch) veröffentlicht, in welchem er auch über die Probleme mit transparenten PNGs im IE 6 schreibt.
Caching
Caching zu aktivieren ist einfach, die korrekte Einstellung erfordert aber etwas mehr Zeit, denn es muss verhindert werden, dass kein veralteter Inhalt ausgeliefert wird. Zwar kann man versuchen das dynamische HTML zu cachen, aber die meisten Seiten würden schon vom Caching statischer Ressourcen profitieren. Falls man also vom CMS verwaltete Ordner wie „export“ oder ein Verzeichnis mit Bildern hat, dann kann man alle Ressourcen dort mit einer langen Gültigkeit versehen. Dies geht im Apache auch sehr einfach:
<IfModule mod_expires.c>
ExpiresActive On
ExpiresDefault "access plus 10 years"
</IfModule>
Will man ein Bild allerdings durch ein Neues ersetzen, so muss man zwangsweise einen neuen Namen vergeben, da es ansonsten nicht erneut heruntergeladen werden würde. Schließlich haben wir dem Browser mitgeteilt, dass es 10 Jahre gültig sei. Der übliche Lösungsansatz dafür ist eine Version oder einen Zeitstempel mit in den Dateinamen aufzunehmen. Problem gelöst! Dieser Vorgang kann entweder manuell oder automatisch durchgeführt werden, dazu später mehr.
Verbindungsaufbau
Bezüglich des Verbindungsaufbaus habe ich bereits in meinem zweiten Beitrag den Slow-Start Trick beschrieben. Allerdings kann man unnötige Verbindungen einfach vermeiden, indem man Ressourcen zusammenfasst, anstelle für jeden kleinen Inhalt eine neue Verbindung aufzubauen. Dies wird üblicherweise durch das Zusammenfassen von JavaScript realisiert, oder durch CSS-Sprites, eine Technik von den ersten Computerspielen, bei denen aus vielen kleinen Bildern eine große Collage erstellt wird, die einmalig runtergeladen wird und dann nur den benötigten Ausschnitt anzeigt. Der beste Ratschlag ist natürlich nichts einzubinden was nicht benötigt wird.
JavaScripte verschwenden Zeit
Browser erfüllen vielfältige Aufgaben, aber die welche am meisten Zeit benötigt ist das Parsen und Ausführen von JavaScript code. Dies ist auch der Grund dafür, dass Browserhersteller ihre JavaScript Engines kontinuierlich verbessern. Als Folge davon ist es ungewiss wie lange so großartige Benchmarks wie das JavaScript Loop Benchmark (englisch) von Greg Reimer noch ihre Gültigkeit bewahren. Ich persönlich sehe das Hauptproblem in der Menge von schlechtem JavaScript code im Internet. Dieser wird von Entwicklern vorbehaltlos kopiert anstelle korrekten Code selbst zu programmieren. JavaScript ist eine mächtige Sprache, und es schockiert mich zu sehen wie schlecht mit ihr umgegangen wird (ok, ich habe das leider auch schon getan).
Aus dem verlinkten Benchmark kann man ablesen wie leicht es ist fatale Fehler einzubauen. Eine clevere Anwendung der Sprachfunktionen führt die Schleife in 15 ms aus. Fehlerhafte Anwendung benötigt dazu 3203ms (Beispiel: HTML Collection (length=1000, looped 100 times), IE7).
Hinzu kommt, dass JavaScript Ausführung in der Regel die Seitendarstellung blockiert. Diesen unschönen Effekt kann man häufig mit Werbebannern beobachten. Die Antwort dazu ist sogenanntes „Unobtrusive JavaScript“, welches das JavaScript an das Ende der Seite verlagert. Allerdings ist das Entfernen von sämtlichen inline JavaScript selten eine realistische Tuningmaßnahme.
Allerdings gibt es etwas was wir tun können und sollten: JavaScript profilen. Die Zeitmessspezifikationen der W3C-Performance Working Group sind noch im Entwurfsstatus, jedoch existiert in der hervorragenden FireBug Erweiterung des Firefox ein Profiler. Die Chrome Developer Tools sind ebenfalls gut geeignet. Beide erlauben die Codeausführung zu messen und optimierbare Hotspots zu finden.
Automatische Verbesserungen
Kürzlich hat Google ein Apache Modul namens mod_pagespeed veröffentlicht. Die Idee hinter mod_pagespeed ist, dass die Best-Practices einfach befolgt werden sollten, da sie keine Probleme verursachen. Allerdings sind manche manuell nicht so einfach umzusetzen, automaisch jedoch schon. Genau das macht mod_pagespeed, indem es HTML nachbearbeitet und Caching ermöglicht. Es funktioniert hervorragend auf nicht optimierten Seiten, aber es kann auch negativen Einfluss haben, da es zusätzlichen Code ausführt. Mein üblicher Rat gilt hier auch: Ergebnisse sollten mit Messungen verifiziert werden. Des weiteren gibt es noch kommerzielle Lösungen welche teilweise auch ein CDN mitliefern.
Eine etwas andere Art einer „automatischen Verbeserung“ ist das HTML5 Boilerplate , eine Webseitenvorlage, welche bereits die besten und bewährten Konfigurationen dokumentiert mitliefert. Ich kann nur empfehlen mal einen Blick darauf zu werfen, insbesondere halte ich den CSS Teil für sehr informativ.
Zusammenfassung
Es ist meine feste Überzeugung, dass der Einsatz der genannten Best-Practices Webseiten schneller macht. Allerdings ist es nicht so einfach die Änderung ausfindig zu machen, die mit 20% Aufwand 80% Verbesserung bringt. Die Werkzeugunterstützung ist leider noch begrenzt und Browser werden auch von Tag zu Tag schneller, so dass wir sowieso am Besten mit einem sauberen Design aufgestellt sind. Falls Sie gerne ausführlich zu dem Thema WPO beraten werden wollen, kontaktieren Sie uns einfach. Wir können herausfinden welcher Teil ihrer Applikation verantwortlich für längere Ladezeiten ist und finden so die Optimierungen, die für Sie den größten Effekt mit geringem Aufwand liefern.
Ich hoffe meine kurze Einführung in das Thema Web Performance Optimierung war aufschlussreich. Ich wünsche gesegnete Weihnachten!
Meine WPO Serie:
- Web Performance Optimierung ist das neue SEO
- Web Performance Optimierung: Die Infrasturktur
- Web Performance Optimierung: Serverseitige Software
- Web Performance Optimierung: Clients
War dieser Beitrag hilfreich?
Weitere Beiträge
von Fabian Lange
26.3.2015 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Fabian Lange
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.