PageSpeed Optimierung

von

PageSpeed Optimierung: Mit Pagespeed Insights das Google Ranking verbessern. Erfahren Sie wie wir mit PageSpeed Optimierung und optimalen Ladezeiten der Website Ihr Ranking optimieren.

PageSpeed Optimierung ist Teil der Suchmaschinenoptimierung (SEO), genauer: der Onpage Optimierung. PageSpeed ist ein Ranking Faktor im Algorithmus der Google Suche. Ebenso von Bedeutung die Anzahl an Crawlern die von Google Spidern  in der Lage sein, mehr Seiten in der vorgegebenen Zeit zu crawlen, die für das Crawlen Ihrer Website zur Verfügung steht. Tatsächlich zeigen aktuelle Daten, dass 50% der Nutzer erwarten, dass eine Website in weniger als 2 Sekunden geladen wird. Die Recherche zeigt auch, dass jede zusätzliche Sekunde der PageSpeed Ihre Conversions um bis zu 20% senken können.

PageSpeed Optimierung

Page Speed ist ein wichtiges Instrument des Online Marketing. Unter Page Speed versteht man die Ladezeit oder die Performance der Website. Ziel einer Website ist es, möglichst hohe Conversionrate zu erlangen und somit hat Page Speed Einfluss auf den Umsatz, wenn die Website oder Online Shop beispielsweise einem gewinnorientierten Unternehmen zugehörig ist. Darum ist es besonders wichtig, dass Ladezeit der Website so kurz wie möglich ausfällt um neue Besucher nicht zu verlieren. Nichts ist mehr frustrierend für einen User als lange Ladezeiten und die Folge ist, dass der User einfach abspringt. So wird mühevoll erarbeiteter Content niemals gelesen, oder Online-Käufe werden nicht getätigt. Darüber hinaus ist die Ladegeschwindigkeit eines von vielen der dynamischen Ranking-Faktoren. Somit würde die Website beim Abspringen des Users an Relevanz verlieren. Page Speed Optimierung ist ein eines von vielen Maßnahmen der OnPage-Optimierung, und diese wiederum ist ein Teil der Suchmaschinenoptimierung (SEO). Der Begriff PageSpeed hat sich durch Google etabliert.

In Zeiten von Brandbandverfügbarkeit sind Ladezeiten von mehr als drei Sekunden nicht hinnehmbar.

Mit PageSpeed Insights die Ladezeit analysieren

Wir empfehlen mit PageSpeed Insights oder webpagetest.org – einen Test durchführen, der die Website Ladezeit analysiert und die Ergebnisse in einer leicht verständlichen Grafik anzeigt. Wenn Sie Ihre Website gegen Mitbewerber testen, können Sie mehrere PageSpeed gleichzeitig ausführen, um zu sehen, wie sie im Vergleich dazu abschneiden. Es gibt drei wichtige Faktoren, die Sie beachten müssen, um den PageSpeed im Auge zu behalten.

  1. Sie müssen auf „time to first byte“ achten, oder wie lange es dauert, bis der Server auf die erste Informationsanfrage reagiert.
  2. Als nächstes möchten Sie sich die gesamte Ladezeit für die Seite ansehen, oder wie lange es dauert, bis alle Seitenelemente vollständig heruntergeladen sind.
  3. Schließlich müssen Sie sich die gesamte Renderzeit ansehen – wie lange es dauert, alles herunterzuladen, was für die Seite benötigt wird, und es bis zur visuellen Fertigstellung zu rendern.

Wenn Sie Probleme mit Ladezeiten haben, müssen Sie feststellen, was die Ursache für die langsame PageSpeed ist. Wenn Sie eine langsame Reaktionszeit haben oder statische Objekte langsam heruntergeladen werden, müssen Sie sich mit der Verbesserung Ihres Cachings oder der Verwendung eines Content Delivery Network befassen. Wenn dynamische Seiten langsam geladen werden, werfen Sie einen Blick auf den Seitencode. Wenn Sie ein Problem mit Ihrer visuellen Render PageSpeed haben, werfen Sie einen Blick auf die externen Ressourcen. Oftmals können Plugins oder Ressourcen von Drittanbietern Ihre Website drastisch verlangsamen.

PageSpeed Insights:

  • Ressourcen beseitigen, die das Rendering blockieren
  • Bilder richtig dimensionieren
  • Nicht sichtbare Bilder aufschieben
  • CSS komprimieren
  • JavaScript komprimieren
  • Nicht verwendete CSS entfernen (Mögliche Einsparung von 12 KB)
  • Bilder effizient codieren
  • Bilder in modernen Formaten bereitstellen (Mögliche Einsparung von 14 KB)
  • Textkomprimierung aktivieren (Mögliche Einsparung von 6 KB)
  • Vorverbindung zu erforderlichen Ursprüngen aufbauen
  • Mehrere Weiterleitungen auf die Seite vermeiden
  • Wichtige Anforderungen vorab laden
  • Videoformate für animierte Inhalte verwenden
  • Vermeidet sehr große Netzwerknutzlasten (Die Gesamtgröße war 231 KB)
  • Verwendet eine effiziente Cache-Richtlinie für statische Inhalte 1 Ressource gefunden
  • Vermeidet eine übermäßige DOM-Größe 353 Elemente
  • Markierungen und Messungen für das Nutzertiming
  • JavaScript-Ausführungszeit 0,6 s
  • Nutzung von Drittanbieter-Code (Code von Drittanbietern hat den Hauptthread 80 ms lang blockiert)

PageSpeed Optimierung

PageSpeed Insights ist ein hilfreiches Werkzeug wenn es um die Einschätzung Ihrer Website geht. Obwohl es die tatsächliche PageSpeed nicht wie webpagetest.org benotet, analysiert es Ihre Website nach den gängigen Best Practices und bietet Vorschläge zur PageSpeed Optimierung. Der PageSpeed ist das erste, was Sie bemerken, wenn Sie eine Website besuchen – wenn die Website zu langsam ist. Der PageSpeed ist ein großer Teil der Benutzererfahrung, so ist es kein Wunder, dass sie offiziell zu einem Ranking-Faktor für mobile Suchanfragen geworden ist und seit langem für den Desktop gilt.

Zahlreiche Beiträge über den Zusammenhang zwischen PageSpeed Optimierung und Bounce-Raten sind zu einigen eher alarmierenden Schlussfolgerungen gekommen: Jede Millisekunde zählt. Mit unserer neuen Website Performance Research wollten wir die beängstigende Statistik um einen Silberstreifen erweitern und beweisen, dass es viel Raum für Verbesserungen in der Performance Ihrer Website gibt.

Wenn es um die Pagespeed Optimierung der Website geht, zeigen wir Ihnen, was die wichtigsten Fehler sind und welche von ihnen diese besondere Aufmerksamkeit erfordern, damit Sie den Prozess der Behebung priorisieren können.

82% Websites mit Ladezeit Problemen

Überraschenderweise ist es für uns das erste Mal, dass wir gesehen haben, dass satte 82% der analysierten Websites Probleme haben, die ihre Leistung erheblich beeinträchtigen. Dies macht Performance Probleme zu den häufigsten auf Websites. Darüber hinaus hatten 44% der analysierten Websites mindestens ein kritisches Problem (gemäß unserer Schweregradklassifizierung für das Site Audit). Positiv zu vermerken ist, dass die Mehrheit der Websites, die Leistungsprobleme haben, diese durch einfache Pagespeed Optimierung und einfache Serverkonfiguration verbessern können. Wir werden uns nun genauer mit den von uns gefundenen Problemen befassen und einige der bewährten Wege zu ihrer Beseitigung vorschlagen.

Probleme bei Website Performance

Wir hoffen, dass diese Daten Ihnen helfen, Ihre Arbeit zu priorisieren und die Anzahl und Schwere der Probleme, die auf Ihrer Website auftreten besser einschätzen. Lassen Sie uns nun einen Blick auf den LadeProzess der Lösung dieser Probleme werfen. Um es einfach zu halten, werden wir unsere Empfehlungen in drei Gruppen unterteilen:

  • Seitengröße verkleinern
  • Steigern der Serverleistung
  • Umleitungen bereinigen

Beginnen wir mit einem einfachen. Redirect-Ketten und Schleifen sind klassische Probleme, die Probleme mit der Website-Leistung verursachen. Wenn Sie die Geduld Ihrer Benutzer mit Redirect-Ketten nicht testen wollen, versuchen Sie, diese zu vermeiden. Außerdem verwirren Redirect-Ketten Bots; ihr Crawling-Budget ist begrenzt, und mit jedem Redirect verliert Ihre Seite ein wenig von ihrem ursprünglichen Rang. Wenn eine Seite 3 oder mehr URLs oder eine Schleife enthält, wird sie als fehlerhaft gekennzeichnet.

Glücklicherweise hatten nur 7% der analysierten Websites dieses Problem, so unsere Studie. Umleitungen von einer Seite zur anderen sind jedoch oft notwendig, wenn es darum geht, eine Website umzubenennen oder umzubenennen, sie auf HTTPS zu migrieren, doppelte Seiten (z.B. „www“ und „non-wwww“ Versionen) zu reduzieren und in vielen anderen Fällen.

Seitengröße optimieren

Je größer und komplexer die Seite und je mehr Ressourcen sie enthält, desto länger dauert das Laden. Es ist wichtig sicherzustellen, dass Ihre Seitengröße sowie die Gesamtgröße von JS- und CSS-Dateien (Transfergröße) 2 MB nicht übersteigt.

In einem Technical Site Audit gilt alles über 2 MB als zu viel und schwer und führt zu einem Fehlern. Auch wenn 2 MB ausreichen, damit eine Seite ihr Leben in vollen Zügen genießen kann, hatten 1% der analysierten Websites noch dieses Problem. Wenn Sie sich unter den 1% befinden, empfehlen wir Ihnen, Ihre Seite auf eine Diät zu setzen und ihre Größe mindestens unter 2MB zu halten.

Auflösung von Bilder und Videos optimieren

Bilder und Videos machen den größten Teil des Gewichts einer Seite aus, das sollte also Ihr Ausgangspunkt sein. Wenn Sie das Format, die Auflösung oder die Qualität Ihrer visuellen Inhalte ändern, kann die Seite erheblich verkleinert werden. Beginnen Sie, indem Sie sich fragen, ob diese Bilder einen echten Wert haben und denken Sie daran, dass manchmal weniger mehr ist.

JavaScript und CSS optimieren

Unsere Recherche ergab, dass 68% der Websites mit unminifizierten JavaScript- und CSS-Dateien enttäuschend waren. Durch die Anpassung Ihrer JavaScript- und CSS-Dateien (Entfernen unnötiger Zeilen, Leerzeichen und Kommentare aus dem Quellcode) reduzieren Sie die Größe Ihrer Ressourcen und damit deren Ladezeit, bieten eine bessere Benutzerfreundlichkeit und verbessern Ihre Suchmaschinenrankings.

  • – JSMin und YUI Compressor. Der YUI-Kompressor kann auch CSS minimieren. Closure Compiler ist ein weiteres praktisches Tool, das Ihr JavaScript analysiert, analysiert, toten Code entfernt und den Rest neu schreibt und minimiert. Die Verdunkelung ist eine weitere Methode der Größenreduzierung, die etwas effektiver ist als die Verkleinerung, obwohl sie aufgrund des Verdunkelungsschritts selbst etwas riskanter ist, Fehler zu erzeugen.

Browser-Caching effizient nutzen

Wenn Sie das Browser-Caching für JavaScript- und CSS-Dateien aktivieren, können Browser die Ressourcen Ihrer Seite speichern und wiederverwenden, ohne sie bei der Anforderung Ihrer Seite erneut herunterladen zu müssen. Auf diese Weise lädt der Browser weniger Daten herunter, was die Ladezeit Ihrer Seite verkürzt. Insgesamt könnte durch diese einfache Lösung bis zu einem Viertel der untersuchten Websites eine deutlich bessere PageSpeed erzielen.

Site Audit

Der Site Audit liefert Ihnen statistische Grafiken, um ein allgemeines Gefühl für die technischen Probleme Ihrer Website zu bekommen; seine Tooltips erklären, worum es bei jedem Problem geht und wie Sie es beheben können. Die Liste der Probleme ist nach Schweregrad in Fehler, Warnungen und Hinweise unterteilt; sie sollten, die kritischsten Fehler zuerst zu beheben. Mit dem Leistungsbericht können Sie auch Ihr Google Analytics-Konto verbinden, um weitere Informationen über die Benutzerfreundlichkeit zu erhalten (Google Analytics Avg Page Interactive Time):

Testen Sie bestimmte Teile Ihrer Website, verwenden Sie thematische Berichte und folgen Sie unseren Empfehlungen, um Ihre Ressourcen zu schonen und mit geringstem Aufwand die besten Ergebnisse zu erzielen.

Das Technical Site Audit markiert eine Seite nur dann als „Zu viele JavaScript- und CSS-Dateien“, wenn sie mehr als 100 Ressourcen enthält, und das ist ziemlich viel. Dennoch stellte sich heraus, dass 1% der analysierten Websites zu viele JavaScript- und CSS-Dateien haben! Achten Sie darauf, dass Sie Ihre Seite nicht mit JavaScript- und CSS-Dateien überladen. Im Allgemeinen gilt: Je weniger Anfragen Sie erhalten, desto besser. Wenn Sie diese Zahl also unter 100 halten, sind Sie auf der sicheren Seite. Erwägen Sie auch, mehrere CSS- und JS-Dateien in einzelne Dateien zusammenzuführen, um den Ladevorgang zu beschleunigen.

Server Performance optimieren

Einer der Gründe für langsame Ladezeiten ist offensichtlich eine große HTML-Seite. Wie wir jedoch herausgefunden haben, stellte sich heraus, dass nur 1% der analysierten Websites eine große HTML-Seitengröße hatten. Woher kommen also die anderen 42% der Probleme mit der langsamen PageSpeed? Sehr oft ist dies auf Serverprobleme zurückzuführen.

Wenn es dem Webserver an Effizienz mangelt, wird die Website, auf die Sie zugreifen möchten, ebenfalls langsam geladen. Sie müssen Ihren Hosting-Service und das bereitgestellte Paket überprüfen; wenn es unzureichend ist, wechseln Sie den Provider oder überlegen Sie, einen dedizierten Server zu installieren. Erfahren Sie hier mehr über die Faktoren, die zu einem schnellen Hosting-Paket beitragen.

PageSpeed Optimierung für Mobile Websites

PageSpeed Optimierung für Mobile Websites ist noch kritischer. Think with Google hilft Ihnen zu schätzen, wie sich die PageSpeed Optimierung Ihrer Website auf Ihre Einnahmen auswirken könnte.

Es gibt andere Faktoren, die die Reaktion Ihres Servers verlangsamen können, wie z.B. langsame Anwendungslogik, langsame Datenbankabfragen, langsames Routing, Frameworks, Bibliotheken, Ressourcen-CPU-Hunger oder Speicherausfall. Verwenden Sie diese Empfehlungen von Google Developers, wie Sie mit diesen Problemen umgehen und die Antwortzeit des Servers verbessern können.

Wie unsere Recherche zeigt, haben 25% der analysierten Websites uncached Javascript- und CSS-Dateien. Dieses Problem wird ausgelöst, wenn das Browser-Caching nicht im Antwortkopf angegeben ist. Einfach ausgedrückt, wenn Sie das Browser-Caching nicht aktivieren, werden die Benutzer bei jedem Besuch Ihrer Seite dieselben Dateien herunterladen.

PageSpeed Optimierung Best Practices

Es gibt viele Faktoren, die sich zu der späteren PageSpeed addieren, und der manuelle Umgang mit allen von ihnen ist eine unerträgliche Aufgabe, aber Sie können sich immer an spezialisierte Tools wenden. Google’s PageSpeed Insights ist ein großartiger Einstieg; es ist kostenlos, funktional und bietet Berichte für mobile und Desktop-Versionen Ihrer Website.

Google verwendet ausschließlich Daten von Google Chrome-Nutzer um festzustellen, ob sie schnell, langsam oder durchschnittlich in Bezug auf die Ladezeit des PageSpeed ist. Für langsame und durchschnittliche Webseiten erhalten Sie Vorschläge zur PageSpeed Optimierung, die eine Liste von Best Practices zur Beschleunigung des Webseite darstellen. Diese Liste ist definitiv einen Blick wert, obwohl sie mit einem Körnchen Salz genommen werden sollte; die Jagd nach der perfekten Punktzahl könnte dazu führen, dass Sie Ihre Zeit verschwenden und eine schlechte Benutzererfahrung schaffen.

Page Speed Tipps

Es gibt viele Ursachen und Gründe für langsame PageSpeeds. Wichtig ist es diese nicht zu ignorieren, sondern dort anzuknüpfen um die Performance der Website zu verbessern. Als Webdesign Agentur möchten wir Ihnen folgende Tipps mit auf dem Weg geben:

  • CSS-, HTML- und JavaScript-Dateien, die größer sind als 150Bytes sind, sollten unbedingt komprimiert werden
  • Valider und schlanker Code: Code-Fehler vermeiden, da solche sich negativ auf das Page Speed auswirken; Code sollte nur das Nötigste beinhalten
  • CSS in externe Datei anlegen, aber:
  • Den relevanten Teil von CSS im <Head>-Bereich einbauen; Vorteil: Der Teil der Website, das dem User angezeigt wird, lädt schneller und der Rest kann auch später geladen werden
  • Bilder und Grafiken sollten mit Tools wie Photoshop komprimiert werden
  • JPEG-Dateien als „Progressive“ statt „Baseline“ anlegen. Vorteil: Bild wird direkt angezeigt, es erhöht nur noch seine Schärfe
  • der Browser sollte Caching nutzen: Dateien bzw. Ressourcen, die sich kaum verändern, sollten „cachebar“ sein; Vorteil: Datei muss nach einigen Tagen neu abgerufen werden, bis dahin bleibt es im Cache gespeichert
  • Asynchrones JavaScript: Beim <script>-Tag das Attribut „defer“ und „async“ verwenden. „defer“ sagt dem Browser, dass der Inhalt erst nach dem Rest geladen werden soll; „async“ sagt dem Browser, dass der Code parallel mit dem Rest geladen werden soll, so behindern sich die Scripte nicht beim Seitenaufbau
  • zudem sollte die Wahl auf einen schnellen Server gefällt werden

Wenn wir eine Website betreuen, achten wir ganz besonders auf Page Speed Performance und selbstverständlich auch auf andere OnPage-Optimierungen.

Links: PageSpeed Optimierung

Bewährte Praktiken zur Beschleunigung Ihrer Website
Das Exceptional Performance Team hat eine Reihe von Best Practices für die Beschleunigung von Webseiten ermittelt. Die Liste umfasst 35 Best Practices, die in 7 Kategorien unterteilt sind.

Minimieren Sie HTTP-Anfragen
80 % der Antwortzeit des Endbenutzers entfallen auf das Front-End. Der größte Teil dieser Zeit wird für das Herunterladen aller Komponenten der Seite benötigt: Bilder, Stylesheets, Skripte, Flash, usw. Die Verringerung der Anzahl der Komponenten reduziert wiederum die Anzahl der HTTP-Anfragen, die zum Rendern der Seite erforderlich sind. Dies ist der Schlüssel zu schnelleren Seiten.
Eine Möglichkeit, die Anzahl der Komponenten auf einer Seite zu reduzieren, besteht darin, das Design der Seite zu vereinfachen. Aber gibt es eine Möglichkeit, Seiten mit umfangreicheren Inhalten zu erstellen und gleichzeitig schnelle Antwortzeiten zu erreichen? Im Folgenden werden einige Techniken vorgestellt, mit denen sich die Anzahl der HTTP-Anfragen reduzieren lässt, während gleichzeitig ein umfangreiches Seitendesign möglich ist.
Kombinierte Dateien sind eine Möglichkeit, die Anzahl der HTTP-Anfragen zu reduzieren, indem alle Skripte in einem einzigen Skript und alle CSS in einem einzigen Stylesheet zusammengefasst werden. Das Kombinieren von Dateien ist schwieriger, wenn die Skripte und Stylesheets von Seite zu Seite variieren, aber wenn Sie dies zu einem Teil Ihres Freigabeprozesses machen, verbessern sich die Antwortzeiten.
CSS-Sprites sind die bevorzugte Methode, um die Anzahl der Bildanfragen zu reduzieren. Kombinieren Sie Ihre Hintergrundbilder zu einem einzigen Bild und verwenden Sie die CSS-Eigenschaften background-image und background-position, um das gewünschte Bildsegment anzuzeigen.
Image Maps fassen mehrere Bilder zu einem einzigen Bild zusammen. Die Gesamtgröße ist in etwa die gleiche, aber durch die Verringerung der Anzahl der HTTP-Anfragen wird die Seite schneller. Image-Maps funktionieren nur, wenn die Bilder auf der Seite zusammenhängend sind, z. B. in einer Navigationsleiste. Die Definition der Koordinaten von Image Maps kann mühsam und fehleranfällig sein. Die Verwendung von Image Maps für die Navigation ist ebenfalls nicht zugänglich und wird daher nicht empfohlen.
Inline-Bilder verwenden das data: URL-Schema, um die Bilddaten in die eigentliche Seite einzubetten. Dadurch kann sich die Größe Ihres HTML-Dokuments erhöhen. Die Kombination von Inline-Bildern in Ihren (zwischengespeicherten) Stylesheets ist eine Möglichkeit, HTTP-Anfragen zu reduzieren und eine Vergrößerung Ihrer Seiten zu vermeiden. Inline-Bilder werden noch nicht von allen wichtigen Browsern unterstützt.
Die Reduzierung der Anzahl der HTTP-Anfragen auf Ihrer Seite ist der erste Ansatzpunkt. Dies ist der wichtigste Leitfaden zur Verbesserung der Leistung für Erstbesucher. Wie in Tenni Theurers Blogbeitrag Browser Cache Usage – Exposed! beschrieben, kommen 40-60 % der täglichen Besucher Ihrer Website mit einem leeren Cache. Eine schnelle Seite für diese Erstbesucher ist der Schlüssel zu einem besseren Benutzererlebnis.

Verwenden Sie ein Content Delivery Network
tag: server
Die Nähe des Nutzers zu Ihrem Webserver wirkt sich auf die Antwortzeiten aus. Wenn Sie Ihre Inhalte auf mehrere, geografisch verteilte Server verteilen, werden Ihre Seiten aus Sicht des Nutzers schneller geladen. Aber wo sollten Sie anfangen?
Als ersten Schritt zur Implementierung geografisch verteilter Inhalte sollten Sie nicht versuchen, Ihre Webanwendung so umzugestalten, dass sie in einer verteilten Architektur funktioniert. Je nach Anwendung könnte die Änderung der Architektur mit gewaltigen Aufgaben wie der Synchronisierung des Sitzungsstatus und der Replikation von Datenbanktransaktionen über verschiedene Serverstandorte hinweg verbunden sein. Versuche, die Distanz zwischen Benutzern und Ihren Inhalten zu verringern, könnten durch diesen Schritt der Anwendungsarchitektur verzögert werden oder ihn gar nicht erst durchlaufen.
Denken Sie daran, dass 80-90 % der Antwortzeit des Endbenutzers auf das Herunterladen aller Komponenten der Seite entfallen: Bilder, Stylesheets, Skripts, Flash usw. Dies ist die Goldene Regel der Leistung. Anstatt mit der schwierigen Aufgabe der Neugestaltung Ihrer Anwendungsarchitektur zu beginnen, ist es besser, zunächst Ihre statischen Inhalte aufzulösen. Dadurch lassen sich nicht nur die Antwortzeiten erheblich verkürzen, sondern dank der Content-Delivery-Networks auch einfacher gestalten.
Ein Content-Delivery-Network (CDN) ist eine Sammlung von Webservern, die über mehrere Standorte verteilt sind, um Inhalte effizienter an die Nutzer zu liefern. Der Server, der für die Bereitstellung von Inhalten für einen bestimmten Benutzer ausgewählt wird, basiert in der Regel auf einem Maß für die Netzwerknähe. So wird beispielsweise der Server mit den wenigsten Netzwerksprüngen oder der Server mit der schnellsten Antwortzeit ausgewählt.
Einige große Internetunternehmen besitzen ein eigenes CDN, aber es ist kostengünstiger, einen CDN-Dienstleister wie Akamai Technologies, EdgeCast oder level3 zu nutzen. Für Start-up-Unternehmen und private Websites können die Kosten für einen CDN-Dienst unerschwinglich sein, aber wenn Ihre Zielgruppe größer und globaler wird, ist ein CDN notwendig, um schnelle Antwortzeiten zu erreichen. Bei Yahoo! verbesserten sich die Antwortzeiten für die Endnutzer um 20 % oder mehr, wenn statische Inhalte von den Anwendungsservern auf ein CDN (sowohl das oben erwähnte CDN eines Drittanbieters als auch das Yahoo-eigene CDN) verschoben wurden. Die Umstellung auf ein CDN ist eine relativ einfache Code-Änderung, die die Geschwindigkeit Ihrer Website drastisch verbessern wird.

Fügen Sie eine Expires- oder eine Cache-Control-Kopfzeile hinzu
tag: server
Es gibt zwei Aspekte dieser Regel:
Für statische Komponenten: Implementieren Sie eine „Never expire“-Politik, indem Sie einen weit in der Zukunft liegenden Expires-Header setzen.
Für dynamische Komponenten: Verwenden Sie einen geeigneten Cache-Control-Header, um den Browser bei bedingten Anfragen zu unterstützen.

Das Design von Webseiten wird immer umfangreicher, was bedeutet, dass mehr Skripte, Stylesheets, Bilder und Flash auf der Seite enthalten sind. Ein Besucher, der Ihre Seite zum ersten Mal besucht, muss möglicherweise mehrere HTTP-Anfragen stellen, aber durch die Verwendung des Expires-Headers machen Sie diese Komponenten cachefähig. Dadurch werden unnötige HTTP-Anfragen bei nachfolgenden Seitenaufrufen vermieden. Expires-Header werden am häufigsten für Bilder verwendet, sollten aber für alle Komponenten verwendet werden, einschließlich Skripte, Stylesheets und Flash-Komponenten.
Browser (und Proxys) verwenden einen Cache, um die Anzahl und Größe der HTTP-Anfragen zu reduzieren, wodurch Webseiten schneller geladen werden. Ein Webserver verwendet den Expires-Header in der HTTP-Antwort, um dem Client mitzuteilen, wie lange eine Komponente zwischengespeichert werden kann. Dies ist ein weit in der Zukunft liegender Expires-Header, der dem Browser mitteilt, dass diese Antwort nicht vor dem 15. April 2010 veraltet sein wird.
Expires: Thu, 15 Apr 2010 20:00:00 GMT

Wenn Ihr Server Apache ist, verwenden Sie die ExpiresDefault-Direktive, um ein Verfallsdatum relativ zum aktuellen Datum festzulegen. In diesem Beispiel für die ExpiresDefault-Direktive wird das Ablaufdatum 10 Jahre vor dem Zeitpunkt der Anfrage festgelegt.
ExpiresDefault „Zugriff plus 10 Jahre“

Beachten Sie, dass Sie bei Verwendung eines weit in der Zukunft liegenden Expires-Headers den Dateinamen der Komponente ändern müssen, wenn sich die Komponente ändert. Bei Yahoo! ist dieser Schritt oft Teil des Erstellungsprozesses: Eine Versionsnummer wird in den Dateinamen der Komponente eingebettet, zum Beispiel yahoo_2.0.6.js.
Die Verwendung einer weit in der Zukunft liegenden Expires-Kopfzeile wirkt sich nur auf die Seitenaufrufe aus, nachdem ein Benutzer Ihre Website bereits besucht hat. Sie hat keinen Einfluss auf die Anzahl der HTTP-Anfragen, wenn ein Benutzer Ihre Website zum ersten Mal besucht und der Cache des Browsers leer ist. Daher hängt die Auswirkung dieser Leistungsverbesserung davon ab, wie oft Benutzer Ihre Seiten mit einem gefüllten Cache aufrufen. (Ein „primed cache“ enthält bereits alle Komponenten der Seite.) Wir haben dies bei Yahoo! gemessen und festgestellt, dass die Anzahl der Seitenaufrufe mit einem primed cache 75-85 % beträgt. Durch die Verwendung eines weit in der Zukunft liegenden Expires-Headers erhöhen Sie die Anzahl der Komponenten, die vom Browser zwischengespeichert und bei nachfolgenden Seitenaufrufen wiederverwendet werden, ohne dass ein einziges Byte über die Internetverbindung des Benutzers gesendet wird.

Gzip-Komponenten
tag: server
Die Zeit, die für die Übertragung einer HTTP-Anfrage und -Antwort über das Netzwerk benötigt wird, kann durch Entscheidungen der Frontend-Ingenieure erheblich reduziert werden. Es stimmt, dass die Bandbreitengeschwindigkeit des Endbenutzers, der Internetdienstanbieter, die Nähe zu Peering-Austauschpunkten usw. außerhalb der Kontrolle des Entwicklungsteams liegen. Aber es gibt noch andere Variablen, die die Antwortzeiten beeinflussen. Die Komprimierung verkürzt die Antwortzeiten, indem sie die Größe der HTTP-Antwort verringert.
Seit HTTP/1.1 zeigen Web-Clients die Unterstützung für Komprimierung mit dem Accept-Encoding-Header in der HTTP-Anfrage an.
Accept-Encoding: gzip, deflate

Wenn der Webserver diesen Header in der Anfrage sieht, kann er die Antwort mit einer der vom Client aufgeführten Methoden komprimieren. Der Webserver teilt dies dem Webclient über den Content-Encoding-Header in der Antwort mit.
Inhaltskodierung: gzip

Gzip ist die derzeit populärste und effektivste Kompressionsmethode. Es wurde vom GNU-Projekt entwickelt und durch RFC 1952 standardisiert. Das einzige andere Kompressionsformat, das Sie wahrscheinlich sehen werden, ist deflate, aber es ist weniger effektiv und weniger populär.
Gzipping reduziert die Antwortgröße im Allgemeinen um etwa 70 %. Etwa 90 % des heutigen Internet-Verkehrs läuft über Browser, die angeblich gzip unterstützen. Wenn Sie Apache verwenden, hängt das Modul, das gzip konfiguriert, von Ihrer Version ab: Apache 1.3 verwendet mod_gzip, während Apache 2.x mod_deflate verwendet.
Es gibt bekannte Probleme mit Browsern und Proxys, die zu einer Diskrepanz zwischen den Erwartungen des Browsers und dem, was er in Bezug auf komprimierte Inhalte erhält, führen können. Glücklicherweise werden diese Fälle immer seltener, da die Verwendung älterer Browser abnimmt. Die Apache-Module helfen dabei, indem sie automatisch geeignete Vary-Antwort-Header hinzufügen.
Server wählen je nach Dateityp aus, was sie komprimieren wollen, sind aber in der Regel zu sehr eingeschränkt, was die Komprimierung angeht. Die meisten Websites komprimieren ihre HTML-Dokumente. Es lohnt sich auch, Ihre Skripte und Stylesheets zu komprimieren, aber viele Websites verpassen diese Möglichkeit. Tatsächlich lohnt es sich, jede Textantwort zu komprimieren, einschließlich XML und JSON. Bild- und PDF-Dateien sollten nicht gzipiert werden, da sie bereits komprimiert sind. Der Versuch, sie zu gzipen, verschwendet nicht nur CPU, sondern kann auch die Dateigröße erhöhen.
Das Gzipen so vieler Dateitypen wie möglich ist eine einfache Möglichkeit, das Gewicht der Seite zu reduzieren und die Benutzerfreundlichkeit zu erhöhen.

Setzen Sie Stylesheets in das
Tag: css
Als wir bei Yahoo! die Leistung untersuchten, entdeckten wir, dass das Verschieben von Stylesheets in den HEAD des Dokuments die Seiten scheinbar schneller lädt. Das liegt daran, dass Stylesheets im HEAD platziert werden, damit die Seite progressiv gerendert werden kann.
Front-End-Ingenieure, denen die Leistung wichtig ist, wollen, dass eine Seite progressiv geladen wird, d. h. der Browser soll den Inhalt so schnell wie möglich anzeigen. Dies ist besonders wichtig für Seiten mit vielen Inhalten und für Benutzer mit langsameren Internetverbindungen. Wie wichtig es ist, den Benutzern visuelles Feedback zu geben, z. B. in Form von Fortschrittsanzeigen, ist gut erforscht und dokumentiert. In unserem Fall ist die HTML-Seite der Fortschrittsanzeiger! Wenn der Browser die Seite nach und nach lädt, dienen die Kopfzeile, die Navigationsleiste, das Logo auf der Seite usw. alle als visuelle Rückmeldung für den Benutzer, der auf die Seite wartet. Dies verbessert die allgemeine Benutzererfahrung.
Das Problem bei der Platzierung von Stylesheets am unteren Ende des Dokuments besteht darin, dass dadurch das progressive Rendering in vielen Browsern, einschließlich Internet Explorer, verhindert wird. Diese Browser blockieren das Rendering, um zu vermeiden, dass Elemente der Seite neu gezeichnet werden müssen, wenn sich ihre Stile ändern. Der Benutzer sieht dann nur eine leere weiße Seite.
Die HTML-Spezifikation besagt eindeutig, dass Stylesheets in den HEAD der Seite aufgenommen werden müssen: „Im Gegensatz zu A darf [LINK] nur im HEAD-Abschnitt eines Dokuments erscheinen, obwohl er beliebig oft vorkommen kann. Keine der beiden Alternativen, d. h. der leere weiße Bildschirm oder das Aufblitzen von ungestyltem Inhalt, ist das Risiko wert. Die optimale Lösung besteht darin, die HTML-Spezifikation zu befolgen und Ihre Stylesheets in den HEAD-Bereich des Dokuments zu laden.

Skripte am unteren Rand platzieren
tag: javascript
Das Problem, das Skripte verursachen, ist, dass sie parallele Downloads blockieren. Die HTTP/1.1-Spezifikation schlägt vor, dass die Browser nicht mehr als zwei Komponenten pro Hostname parallel herunterladen. Wenn Sie Ihre Bilder von mehreren Hostnamen aus bereitstellen, können Sie erreichen, dass mehr als zwei Downloads parallel stattfinden. Während ein Skript heruntergeladen wird, startet der Browser jedoch keine weiteren Downloads, auch nicht unter verschiedenen Hostnamen.
In manchen Situationen ist es nicht einfach, Skripte nach unten zu verschieben. Wenn das Skript z. B. document.write verwendet, um einen Teil des Seiteninhalts einzufügen, kann es nicht nach unten verschoben werden. Es könnte auch Probleme mit dem Scoping geben. In vielen Fällen gibt es Möglichkeiten, diese Situationen zu umgehen.
Ein alternativer Vorschlag, der oft gemacht wird, ist die Verwendung von zeitversetzten Skripten. Das DEFER-Attribut zeigt an, dass das Skript kein document.write enthält, und ist ein Hinweis für die Browser, dass sie mit dem Rendering fortfahren können. Leider unterstützt Firefox das DEFER-Attribut nicht. Im Internet Explorer kann das Skript zurückgestellt werden, aber nicht so weit wie gewünscht. Wenn ein Skript verschoben werden kann, kann es auch an den unteren Rand der Seite verschoben werden. Dadurch werden Ihre Webseiten schneller geladen.

Vermeiden Sie CSS-Ausdrücke
tag: css
CSS-Ausdrücke sind eine mächtige (und gefährliche) Möglichkeit, CSS-Eigenschaften dynamisch festzulegen. Sie wurden im Internet Explorer ab Version 5 unterstützt, sind aber seit IE8 veraltet. So könnte beispielsweise die Hintergrundfarbe mithilfe von CSS-Ausdrücken so eingestellt werden, dass sie jede Stunde wechselt:
background-color: expression( (new Date()).getHours()%2 ? „#B8D4FF“ : „#F08A00“ );

Wie hier gezeigt, akzeptiert die Methode expression einen JavaScript-Ausdruck. Die CSS-Eigenschaft wird auf das Ergebnis der Auswertung des JavaScript-Ausdrucks gesetzt. Die expression-Methode wird von anderen Browsern ignoriert und ist daher nützlich, um Eigenschaften im Internet Explorer festzulegen, die für eine einheitliche Darstellung in allen Browsern erforderlich sind.
Das Problem mit Ausdrücken ist, dass sie häufiger ausgewertet werden, als die meisten Leute erwarten. Sie werden nicht nur ausgewertet, wenn die Seite gerendert und in der Größe verändert wird, sondern auch, wenn die Seite gescrollt wird und sogar, wenn der Benutzer die Maus über die Seite bewegt. Durch Hinzufügen eines Zählers zum CSS-Ausdruck können wir verfolgen, wann und wie oft ein CSS-Ausdruck ausgewertet wird. Wenn man mit der Maus über die Seite fährt, können leicht mehr als 10.000 Auswertungen entstehen.
Eine Möglichkeit, die Anzahl der Auswertungen Ihres CSS-Ausdrucks zu reduzieren, besteht in der Verwendung von einmaligen Ausdrücken, bei denen die Stileigenschaft bei der ersten Auswertung des Ausdrucks auf einen expliziten Wert gesetzt wird, der den CSS-Ausdruck ersetzt. Wenn die Stileigenschaft während der gesamten Lebensdauer der Seite dynamisch festgelegt werden muss, ist die Verwendung von Event-Handlern anstelle von CSS-Ausdrücken ein alternativer Ansatz. Wenn Sie CSS-Ausdrücke verwenden müssen, bedenken Sie, dass diese möglicherweise Tausende von Malen ausgewertet werden und die Leistung Ihrer Seite beeinträchtigen können.

Machen Sie JavaScript und CSS extern
tag: javascript, css
Viele dieser Leistungsregeln beziehen sich darauf, wie externe Komponenten verwaltet werden. Bevor Sie diese Überlegungen anstellen, sollten Sie sich jedoch eine grundlegendere Frage stellen: Sollten JavaScript und CSS in externen Dateien enthalten sein oder in die Seite selbst eingefügt werden?
Die Verwendung externer Dateien führt in der Praxis in der Regel zu schnelleren Seiten, da die JavaScript- und CSS-Dateien vom Browser zwischengespeichert werden. JavaScript und CSS, die in HTML-Dokumente eingebettet sind, werden bei jeder Anforderung des HTML-Dokuments heruntergeladen. Dies verringert die Anzahl der erforderlichen HTTP-Anfragen, erhöht aber die Größe des HTML-Dokuments. Befinden sich JavaScript und CSS hingegen in externen Dateien, die vom Browser zwischengespeichert werden, verringert sich die Größe des HTML-Dokuments, ohne dass sich die Zahl der HTTP-Anfragen erhöht.
Der Schlüsselfaktor ist also die Häufigkeit, mit der externe JavaScript- und CSS-Komponenten im Verhältnis zur Anzahl der angeforderten HTML-Dokumente zwischengespeichert werden. Dieser Faktor ist zwar schwer zu quantifizieren, kann aber anhand verschiedener Metriken gemessen werden. Wenn Benutzer auf Ihrer Website mehrere Seitenaufrufe pro Sitzung haben und viele Ihrer Seiten dieselben Skripte und Stylesheets wiederverwenden, besteht ein größerer potenzieller Nutzen aus gecachten externen Dateien.
Viele Websites liegen in der Mitte zwischen diesen beiden Kriterien. Für diese Websites ist es im Allgemeinen die beste Lösung, JavaScript und CSS als externe Dateien bereitzustellen. Die einzige Ausnahme, bei der das Inlining vorzuziehen ist, sind Homepages, wie die Startseite von Yahoo! und My Yahoo! Bei Homepages, die nur wenige (vielleicht nur einen) Seitenaufruf pro Sitzung haben, kann das Inlining von JavaScript und CSS zu schnelleren Antwortzeiten für den Endbenutzer führen.
Für Startseiten, die in der Regel der erste von vielen Seitenaufrufen sind, gibt es Techniken, die die Verringerung der HTTP-Anfragen, die das Inlining mit sich bringt, sowie die durch die Verwendung externer Dateien erzielten Caching-Vorteile nutzen. Eine dieser Techniken besteht darin, JavaScript und CSS in die Startseite einzubinden, aber die externen Dateien dynamisch herunterzuladen, nachdem die Seite geladen wurde. Nachfolgende Seiten würden auf die externen Dateien verweisen, die sich bereits im Cache des Browsers befinden sollten.

DNS-Suchvorgänge reduzieren
tag: Inhalt
Das Domain Name System (DNS) ordnet Hostnamen IP-Adressen zu, so wie Telefonbücher die Namen von Personen ihren Telefonnummern zuordnen. Wenn Sie www.yahoo.com in Ihren Browser eingeben, gibt ein vom Browser kontaktierter DNS-Resolver die IP-Adresse dieses Servers zurück. DNS hat seinen Preis. Es dauert in der Regel 20-120 Millisekunden, bis DNS die IP-Adresse für einen bestimmten Hostnamen gefunden hat. Der Browser kann nichts von diesem Hostnamen herunterladen, bis die DNS-Abfrage abgeschlossen ist.
DNS-Suchvorgänge werden zur Verbesserung der Leistung zwischengespeichert. Diese Zwischenspeicherung kann auf einem speziellen Zwischenspeicher-Server erfolgen, der vom Internetdienstanbieter oder dem lokalen Netzwerk des Benutzers unterhalten wird, aber es gibt auch eine Zwischenspeicherung, die auf dem Computer des einzelnen Benutzers erfolgt. Die DNS-Informationen verbleiben im DNS-Cache des Betriebssystems (der „DNS-Client-Dienst“ unter Microsoft Windows). Die meisten Browser verfügen über einen eigenen Cache, der vom Cache des Betriebssystems getrennt ist. Solange der Browser einen DNS-Datensatz in seinem eigenen Cache hält, belästigt er das Betriebssystem nicht mit einer Anfrage nach dem Datensatz.
Der Internet Explorer speichert DNS-Abfragen standardmäßig 30 Minuten lang im Cache, wie in der Registrierungseinstellung DnsCacheTimeout festgelegt. Firefox speichert DNS-Suchvorgänge für 1 Minute, gesteuert durch die Konfigurationseinstellung network.dnsCacheExpiration. (Fasterfox ändert dies auf 1 Stunde.)
Wenn der DNS-Cache des Clients leer ist (sowohl für den Browser als auch für das Betriebssystem), entspricht die Anzahl der DNS-Lookups der Anzahl der eindeutigen Hostnamen auf der Webseite. Dazu gehören die in der URL der Seite verwendeten Hostnamen, Bilder, Skriptdateien, Stylesheets, Flash-Objekte usw. Durch die Verringerung der Anzahl der eindeutigen Hostnamen wird die Anzahl der DNS-Abfragen reduziert.
Durch die Verringerung der Anzahl eindeutiger Hostnamen kann der Umfang des parallelen Herunterladens der Seite reduziert werden. Die Vermeidung von DNS-Abfragen verkürzt die Antwortzeiten, aber die Reduzierung paralleler Downloads kann die Antwortzeiten erhöhen. Ich empfehle, diese Komponenten auf mindestens zwei, aber nicht mehr als vier Hostnamen aufzuteilen. Dies ist ein guter Kompromiss zwischen der Verringerung von DNS-Abfragen und der Ermöglichung eines hohen Maßes an parallelen Downloads.

Minimieren Sie JavaScript und CSS
tag: javascript, css
Bei der Minifizierung werden unnötige Zeichen aus dem Code entfernt, um dessen Größe zu verringern und so die Ladezeiten zu verbessern. Bei der Minifizierung von Code werden alle Kommentare sowie nicht benötigte Leerzeichen (Leerzeichen, Zeilenumbruch und Tabulator) entfernt. Im Falle von JavaScript verbessert dies die Antwortzeiten, da die Größe der heruntergeladenen Datei verringert wird. Zwei beliebte Tools zum Mining von JavaScript-Code sind JSMin und YUI Compressor. Der YUI Compressor kann auch CSS verkleinern.
Obfuscation ist eine alternative Optimierung, die auf Quellcode angewendet werden kann. Sie ist komplexer als die Minifizierung und führt daher mit größerer Wahrscheinlichkeit zu Fehlern als Folge des Obfuskationsschritts selbst. In einer Untersuchung von zehn US-amerikanischen Websites erzielte die Minifizierung eine Größenreduzierung von 21 % gegenüber 25 % bei der Obfuskation. Obwohl die Obfuskation eine höhere Größenreduzierung aufweist, ist die Minifizierung von JavaScript weniger riskant.
Neben der Minifizierung externer Skripte und Stile können und sollten auch eingebettete

Eine Alternative in PHP wäre, eine Funktion namens insertScript zu erstellen.

Diese Funktion verhindert nicht nur, dass ein und dasselbe Skript mehrfach eingefügt wird, sondern könnte auch andere Probleme mit Skripten lösen, wie z. B. die Überprüfung von Abhängigkeiten und das Hinzufügen von Versionsnummern zu Skript-Dateinamen, um zukünftige Expires-Header zu unterstützen.

ETags konfigurieren
tag: server
Entity-Tags (ETags) sind ein Mechanismus, den Webserver und Browser verwenden, um festzustellen, ob die Komponente im Cache des Browsers mit der Komponente auf dem Ursprungsserver übereinstimmt. (Eine „Entität“ ist ein anderes Wort für eine „Komponente“: Bilder, Skripte, Stylesheets usw.) ETags wurden hinzugefügt, um einen flexibleren Mechanismus für die Validierung von Entitäten zu bieten als das Datum der letzten Änderung. Ein ETag ist eine Zeichenfolge, die eine bestimmte Version einer Komponente eindeutig identifiziert. Die einzigen Formatbeschränkungen sind, dass die Zeichenkette in Anführungszeichen stehen muss. Der Ursprungsserver gibt das ETag der Komponente mit Hilfe des ETag-Antwort-Headers an.
HTTP/1.1 200 OK
Zuletzt geändert: Tue, 12 Dec 2006 03:03:59 GMT
ETag: „10c24bc-4ab-457e1c1f“
Inhalt-Länge: 12195

Wenn der Browser später eine Komponente validieren muss, verwendet er den If-None-Match-Header, um den ETag an den Ursprungsserver zurückzugeben. Wenn die ETags übereinstimmen, wird ein 304-Statuscode zurückgegeben, wodurch sich die Antwort in diesem Beispiel um 12195 Bytes verringert.
GET /i/yahoo.gif HTTP/1.1
Host: us.yimg.com
If-Modified-Since: Tue, 12 Dec 2006 03:03:59 GMT
If-None-Match: „10c24bc-4ab-457e1c1f“
HTTP/1.1 304 Nicht geändert

Das Problem mit ETags ist, dass sie normalerweise mit Attributen konstruiert werden, die sie für einen bestimmten Server, der eine Website hostet, einzigartig machen. ETags stimmen nicht überein, wenn ein Browser die Originalkomponente von einem Server erhält und später versucht, diese Komponente auf einem anderen Server zu validieren, eine Situation, die auf Websites, die einen Cluster von Servern zur Bearbeitung von Anfragen verwenden, nur allzu häufig vorkommt. Standardmäßig betten sowohl Apache als auch IIS Daten in den ETag ein, die die Wahrscheinlichkeit, dass der Gültigkeitstest auf Websites mit mehreren Servern erfolgreich ist, drastisch verringern.
Das ETag-Format für Apache 1.3 und 2.x ist inode-size-timestamp. Obwohl sich eine bestimmte Datei auf mehreren Servern im selben Verzeichnis befinden kann und dieselbe Dateigröße, dieselben Berechtigungen, denselben Zeitstempel usw. hat, unterscheidet sich ihre Inode von einem Server zum anderen.
IIS 5.0 und 6.0 haben ein ähnliches Problem mit ETags. Das Format für ETags auf IIS ist Filetimestamp:ChangeNumber. Eine ChangeNumber ist ein Zähler, der dazu dient, Konfigurationsänderungen am IIS zu verfolgen. Es ist unwahrscheinlich, dass die ChangeNumber auf allen IIS-Servern hinter einer Website dieselbe ist.
Das Ergebnis ist, dass die ETags, die von Apache und IIS für genau dieselbe Komponente generiert werden, nicht von einem Server zum anderen übereinstimmen. Wenn die ETags nicht übereinstimmen, erhält der Benutzer nicht die kleine, schnelle 304-Antwort, für die ETags entwickelt wurden, sondern eine normale 200-Antwort zusammen mit allen Daten für die Komponente. Wenn Sie Ihre Website auf nur einem Server hosten, ist das kein Problem. Wenn Ihre Website jedoch auf mehreren Servern gehostet wird und Sie Apache oder IIS mit der Standard-ETag-Konfiguration verwenden, erhalten Ihre Benutzer langsamere Seiten, Ihre Server sind stärker ausgelastet, Sie verbrauchen mehr Bandbreite und Proxys können Ihre Inhalte nicht effizient zwischenlagern. Selbst wenn Ihre Komponenten eine weit in der Zukunft liegende Expires-Kopfzeile haben, wird immer noch eine bedingte GET-Anforderung gestellt, wenn der Benutzer auf Reload oder Refresh klickt.
Wenn Sie die Vorteile des flexiblen Validierungsmodells, das ETags bieten, nicht nutzen, ist es besser, den ETag ganz zu entfernen. Der Last-Modified-Header validiert auf der Grundlage des Zeitstempels der Komponente. Und durch das Entfernen des ETag wird die Größe der HTTP-Header sowohl in der Antwort als auch in den nachfolgenden Anforderungen reduziert. Dieser Microsoft Support-Artikel beschreibt, wie ETags entfernt werden können. In Apache wird dies einfach durch Hinzufügen der folgenden Zeile zu Ihrer Apache-Konfigurationsdatei erreicht:
FileETag keine

Ajax cachefähig machen
tag: Inhalt
Einer der angeführten Vorteile von Ajax ist, dass es dem Benutzer ein sofortiges Feedback gibt, da es Informationen asynchron vom Backend-Webserver anfordert. Die Verwendung von Ajax ist jedoch keine Garantie dafür, dass der Benutzer nicht Däumchen dreht, bis diese asynchronen JavaScript- und XML-Antworten zurückkommen. In vielen Anwendungen hängt es von der Art der Verwendung von Ajax ab, ob der Benutzer warten muss oder nicht. In einem webbasierten E-Mail-Client wird der Benutzer beispielsweise auf die Ergebnisse einer Ajax-Anfrage warten müssen, um alle E-Mail-Nachrichten zu finden, die seinen Suchkriterien entsprechen. Es ist wichtig, daran zu denken, dass „asynchron“ nicht „sofort“ bedeutet.
Um die Leistung zu verbessern, ist es wichtig, diese Ajax-Antworten zu optimieren. Die wichtigste Methode zur Verbesserung der Ajax-Leistung besteht darin, die Antworten zwischenspeicherfähig zu machen, wie unter Hinzufügen eines Expires- oder eines Cache-Control-Headers erläutert. Einige der anderen Regeln gelten auch für Ajax:
Gzip-Komponenten
DNS-Suchvorgänge reduzieren
JavaScript verkleinern
Redirects vermeiden
ETags konfigurieren

Lassen Sie uns ein Beispiel betrachten. Ein Web 2.0-E-Mail-Client könnte Ajax verwenden, um das Adressbuch des Benutzers zur automatischen Vervollständigung herunterzuladen. Wenn der Benutzer sein Adressbuch seit der letzten Verwendung der E-Mail-Webanwendung nicht geändert hat, könnte die vorherige Adressbuchantwort aus dem Cache gelesen werden, wenn diese Ajax-Antwort mit einem zukünftigen Expires- oder Cache-Control-Header cachefähig gemacht wurde. Der Browser muss darüber informiert werden, wann er eine zuvor zwischengespeicherte Adressbuchantwort verwenden soll, anstatt eine neue anzufordern. Dies könnte durch Hinzufügen eines Zeitstempels zur Ajax-URL des Adressbuchs geschehen, der angibt, wann der Benutzer sein Adressbuch zuletzt geändert hat, z. B. &t=1190241612. Wenn das Adressbuch seit dem letzten Download nicht geändert wurde, bleibt der Zeitstempel gleich und das Adressbuch wird aus dem Cache des Browsers gelesen, wodurch ein zusätzlicher HTTP-Roundtrip vermieden wird. Wenn der Benutzer sein Adressbuch geändert hat, sorgt der Zeitstempel dafür, dass die neue URL nicht mit der Antwort aus dem Cache übereinstimmt, und der Browser fordert die aktualisierten Adressbucheinträge an.
Auch wenn Ihre Ajax-Antworten dynamisch erstellt werden und möglicherweise nur für einen einzigen Benutzer gelten, können sie dennoch in den Cache gestellt werden. Auf diese Weise werden Ihre Web 2.0-Anwendungen schneller.

Den Puffer frühzeitig leeren
tag: server
Wenn Benutzer eine Seite anfordern, kann es zwischen 200 und 500 ms dauern, bis der Backend-Server die HTML-Seite zusammengesetzt hat. Während dieser Zeit wartet der Browser im Leerlauf auf das Eintreffen der Daten. In PHP steht Ihnen die Funktion flush() zur Verfügung. Sie ermöglicht es Ihnen, Ihre teilweise fertige HTML-Antwort an den Browser zu senden, so dass der Browser mit dem Abrufen von Komponenten beginnen kann, während Ihr Backend mit dem Rest der HTML-Seite beschäftigt ist. Der Vorteil ist vor allem bei stark ausgelasteten Backends oder leichten Frontends zu sehen.
Eine gute Stelle, um das Flushing in Betracht zu ziehen, ist direkt nach dem HEAD, da das HTML für den Head in der Regel einfacher zu produzieren ist und es Ihnen ermöglicht, CSS- und JavaScript-Dateien einzubinden, die der Browser parallel abrufen kann, während das Backend noch mit der Verarbeitung beschäftigt ist.
Beispiel:
…



…

Yahoo! Search hat Pionierarbeit geleistet, indem es die Vorteile dieser Technik durch Forschung und echte Benutzertests nachgewiesen hat.

Verwenden Sie GET für AJAX-Anfragen
tag: server
Das Yahoo!-Mail-Team fand heraus, dass bei der Verwendung von XMLHttpRequest POST in den Browsern als zweistufiger Prozess implementiert ist: zuerst werden die Header gesendet, dann die Daten. Daher ist es am besten, GET zu verwenden, das nur ein TCP-Paket zum Senden benötigt (es sei denn, Sie haben eine Menge Cookies). Die maximale URL-Länge im IE beträgt 2K, wenn Sie also mehr als 2K Daten senden, können Sie GET möglicherweise nicht verwenden.
Ein interessanter Nebeneffekt ist, dass sich POST, ohne tatsächlich Daten zu senden, wie GET verhält. Ausgehend von den HTTP-Spezifikationen ist GET für das Abrufen von Informationen gedacht, so dass es (semantisch) sinnvoll ist, GET zu verwenden, wenn Sie nur Daten anfordern, im Gegensatz zum Senden von Daten, die serverseitig gespeichert werden sollen.

Post-Load-Komponenten
tag: Inhalt
Sie können sich Ihre Seite genauer ansehen und sich fragen: „Was ist unbedingt erforderlich, um die Seite zunächst zu rendern?“. Der Rest des Inhalts und der Komponenten kann warten.
JavaScript ist ein idealer Kandidat für die Aufteilung vor und nach dem onload-Ereignis. Wenn Sie z. B. JavaScript-Code und Bibliotheken haben, die Drag & Drop und Animationen ausführen, können diese warten, da das Ziehen von Elementen auf der Seite erst nach dem ersten Rendering erfolgt. Auch versteckte Inhalte (Inhalte, die erst nach einer Benutzeraktion angezeigt werden) und Bilder unterhalb des Falzes kommen für das Nachladen in Frage.
Tools, die Sie bei Ihren Bemühungen unterstützen: Mit dem YUI Image Loader können Sie Bilder unterhalb der Falz verzögern und mit dem YUI Get Utility können Sie JS und CSS einfach und schnell einbinden. Ein Beispiel aus der Praxis finden Sie auf der Yahoo! Homepage mit aktiviertem Firebug Net Panel.
Es ist gut, wenn die Leistungsziele im Einklang mit anderen Best Practices der Webentwicklung stehen. In diesem Fall besagt die Idee des Progressive Enhancement, dass JavaScript, wenn es unterstützt wird, das Benutzererlebnis verbessern kann, aber Sie müssen sicherstellen, dass die Seite auch ohne JavaScript funktioniert. Nachdem Sie also sichergestellt haben, dass die Seite einwandfrei funktioniert, können Sie sie mit einigen nachgeladenen Skripten verbessern, die Ihnen weitere Funktionen wie Drag & Drop und Animationen bieten.

Komponenten vorladen
tag: Inhalt
Preload mag wie das Gegenteil von Post-Load aussehen, verfolgt aber ein anderes Ziel. Durch das Vorladen von Komponenten können Sie die Zeit nutzen, in der der Browser nicht aktiv ist, und Komponenten (wie Bilder, Stile und Skripte) anfordern, die Sie in der Zukunft benötigen. Wenn der Benutzer die nächste Seite aufruft, befinden sich die meisten Komponenten bereits im Cache, und die Seite wird für den Benutzer viel schneller geladen.
Es gibt verschiedene Arten des Vorladens:
Unbedingtes Vorladen – sobald onload ausgelöst wird, holen Sie einige zusätzliche Komponenten ab. Auf google.com finden Sie ein Beispiel dafür, wie ein Sprite-Bild beim Laden angefordert wird. Dieses Sprite-Bild wird auf der Startseite von google.com nicht benötigt, wohl aber auf der darauffolgenden Suchergebnisseite.
Bedingtes Vorladen – auf der Grundlage einer Benutzeraktion stellen Sie eine Vermutung an, wohin der Benutzer als Nächstes geht, und laden entsprechend vor. Auf search.yahoo.com können Sie sehen, wie einige zusätzliche Komponenten angefordert werden, nachdem Sie mit der Eingabe in das Eingabefeld begonnen haben.
Antizipiertes Vorladen – Vorladen im Voraus, bevor ein Redesign gestartet wird. Nach einer Umgestaltung hört man oft: „Die neue Website ist toll, aber sie ist langsamer als vorher“. Ein Teil des Problems könnte darin bestehen, dass die Nutzer Ihre alte Website mit vollem Cache besucht haben, die neue jedoch immer mit leerem Cache. Sie können diesen Nebeneffekt abmildern, indem Sie einige Komponenten vorladen, bevor Sie die Neugestaltung überhaupt gestartet haben. Ihre alte Website kann die Zeit, in der der Browser inaktiv ist, nutzen, um Bilder und Skripte abzurufen, die von der neuen Website verwendet werden.

Reduzieren Sie die Anzahl der DOM-Elemente
tag: Inhalt
Eine komplexe Seite bedeutet mehr herunterzuladende Bytes und einen langsameren DOM-Zugriff in JavaScript. Es macht einen Unterschied, ob Sie 500 oder 5000 DOM-Elemente auf der Seite durchlaufen, wenn Sie zum Beispiel einen Event-Handler hinzufügen wollen.
Eine hohe Anzahl von DOM-Elementen kann ein Anzeichen dafür sein, dass etwas am Markup der Seite verbessert werden sollte, ohne dass unbedingt Inhalte entfernt werden müssen. Verwenden Sie verschachtelte Tabellen für das Layout? Fügen Sie mehr

s ein, nur um Layoutprobleme zu beheben? Vielleicht gibt es einen besseren und semantisch korrekteren Weg, Ihr Markup zu gestalten.
Eine große Hilfe beim Layout sind die YUI-CSS-Utilities: grids.css kann Ihnen beim Gesamtlayout helfen, fonts.css und reset.css können Ihnen helfen, die Standardformatierungen des Browsers zu entfernen. Dies ist eine Chance, neu anzufangen und über Ihr Markup nachzudenken, z. B.

s nur dann zu verwenden, wenn es semantisch Sinn macht, und nicht, weil es eine neue Zeile rendert.
Die Anzahl der DOM-Elemente ist leicht zu testen, geben Sie einfach in die Konsole von Firebug ein:
document.getElementsByTagName(‚*‘).length
Und wie viele DOM-Elemente sind zu viele? Prüfen Sie andere ähnliche Seiten, die ein gutes Markup haben. Die Yahoo!-Homepage ist zum Beispiel eine sehr umfangreiche Seite und hat trotzdem weniger als 700 Elemente (HTML-Tags).

Komponenten über Domänen hinweg aufteilen
tag: Inhalt
Die Aufteilung von Komponenten ermöglicht es Ihnen, parallele Downloads zu maximieren. Achten Sie darauf, dass Sie nicht mehr als 2 bis 4 Domains verwenden, da die DNS-Suche sonst nicht funktioniert. Sie können zum Beispiel Ihren HTML- und dynamischen Inhalt auf www.example.org hosten und die statischen Komponenten auf static1.example.org und static2.example.org aufteilen.
Weitere Informationen finden Sie in „Maximizing Parallel Downloads in the Carpool Lane“ von Tenni Theurer und Patty Chi.

Minimieren Sie die Anzahl der iframes
tag: Inhalt
Mit iframes kann ein HTML-Dokument in das übergeordnete Dokument eingefügt werden. Es ist wichtig zu verstehen, wie iframes funktionieren, damit sie effektiv eingesetzt werden können.