Ein kritischer Blick auf PageSpeed Insights

Das Tool „PageSpeed Insights“ vom Suchmaschinenriesen Google ist in aller Munde. Sowohl Seitenbetreiber, die die Performance ihrer Internetseite prüfen wollen, als auch von SEO-Agenturen, welche ein nützliches Tool nutzen können, um die technischen Anpassungen der Zielseite vorzunehmen.

Da das Ergebnis eines Insight-Tests mit einer Punktzahl bis 100 bewertet ist, wird dies oft als Vergleichskriterium für Internetseiten genutzt. Ein maximaler Wert scheint hier oft das Ziel jeder Optimierung zu sein, viele Websites geben Tipps und Hinweise, wie eine Punktzahl von 100 erreicht werden kann, und es existieren bereits Programmierschnittstellen zur individuellen Integration der Testergebnisse in andere Softwareumgebungen.

Hat man sich mit den Ergebnissen von Google Page Speed Insights beschäftigt, stellt man schnell fest, dass sich alles darum dreht, die Ladegeschwindigkeit der Internetseite zu verbessern, indem man die geforderte Bandbreite reduziert. Anders gesagt: Die zu ladenden Ressourcen der Website sollen laut Google minimiert werden.

In diesem Artikel werfen wir einen kritischen Blick auf die Resultate. Vorab sei jedoch gesagt, dass die Optimierungstipps von Google nicht falsch sind. Sie sind jedoch häufig überzogen oder treffen nicht den Kern einer performancebasierten Optimierungsstrategie. Kurz gesagt: Die Ergebnisse eines PageSpeed Insight-Tests sollten nicht als alleiniges Kriterium für eine gute Ladegeschwindigkeit dienen.

Die Messung der Ladezeit stellt nur einen Teilbereich dar

PageSpeed Insights bewertet akribisch den sogenannten Response (zu dt.: Antwort) – das sind die Daten, die der Browser vom Server angefordert hat. Der Service zielt darauf ab, die Daten des Response weitesgehend zu minimieren.

Crashkurs für das HTTP-Protokoll

Was dem User vorenthalten wird, ist die Tatsache, dass der Response nur einen kleinen Teil jeder Browser-Anfrage ausmacht. Die Abfolge einer jeden Serveranfrage ist im sogenannten HTTP-Protokoll definiert: Bevor der Response gesendet wird, passieren drei entscheidene Dinge:

  1. Den Server suchen
  2. Mit dem Server verbinden
  3. Auf eine Antwort warten

Erst an vierter Stelle erfolgt der Response. Nicht nur dieser Schritt kostet Zeit, sondern auch die ersten drei Schritte. Dabei ist es unerheblich, wie groß die gesendeten Daten aus Schritt vier sind – die ersten drei Schritte kosten immer Zeit, egal wie groß die angeforderte Datenmenge ist.

Als Beispiel dient eine Anfrage an eine Website aus den Vereinigten Staaten. Weil Signale nicht schneller als das Licht gesendet bzw. empfangen werden können, liegt die physikalische Untergrenze für das Senden von Datenpaketen bei 80 Millisekunden. Das bedeutet, dass unabhängig von der Performance-Optimierung immer 80 ms zur Anfrage zugerechnet werden müssen.

Warum ist das so wichtig?

Um zu verdeutlichen, dass die ersten drei Schritte durchaus relevant für die Optimierung sind, zeigen wir hier, am Beispiel der Website „whitehouse.gov“, wie die Verteilung der Anforderungszeiten aussieht.

Die Messung erfolgte hierbei mit den Entwicklertools vom Google-eigenen Browser Chrome. Während nur vier Millisekunden für die Verarbeitung und des Downloads für den Inhalt ( = Bandbreite) beansprucht werden, sind es 35 ms, die für die Konnektierung an der Server (Schritt 1-3) draufgehen.

Für spätere Abschnitte ist der Begriff „Latenz“ wichtig. Dieser bezeichnet die Zeit, die für die Konnektierung beansprucht wird (Schritt 1-3). Vor dem Empfang des Response gibt es immer eine gewisse Latenzzeit.

Nur ein Teilbereich wird bewertet

Da, wie oben schon genannt, die PageSpeed Insights lediglich auf die Optimierung der Bandbreite (Content Download) abzielt, wird der Eindruck erweckt, man könne mit der Verbesserung dieser Ladezeit die Gesamtladezeit der Internetseite wesentlich beeinflussen. Tatsächlich müsste jedoch zusätzlich Schritt 1-3 näher beleuchtet werden, um ein fundiertes Ergebnis zu liefern.

Die Ergebnisse zielen nicht speziell auf das Webseiten-Angebot ab

PageSpeed Insights misst Bereiche, die die Ladegeschwindigkeit der Seite betreffen. Für große Internetseiten sind diese gar nicht so einfach zu implementieren. Und je nachdem, wie die Website entworfen ist, können einige Optimierungen wirksamer als andere sein. Das bedeutet nicht, dass sich Entwickler großer Internetseiten keine Gedanken über die Testergebnisse von PageSpeed Insights machen sollten – allerdings gelten die Hinweise aus dem Tool lediglich als Best-Practice.

Eine kleine Visitenkarten-Internetseite, die per Definition schon eine geringe Menge an Resourcen benötigt, kann die Anforderungen von PageSpeed Insights leichter erfüllen als ein großes Portal, welches für den Betrieb zusätzliche Ressourcen, Bibliotheken und Drittanbieter-Anwendungen benötigt.

Um hier näher ins Detail zu gehen, versuchen wir, einige Tests von PageSpeed Insights kritisch zu hinterfragen:

„Bilder optimieren“

Natürlich ist die Reduzierung von Bildgrößen ein wichtiger Faktor. PageSpeed Insights prüft jedoch nur, inwieweit eine Grafik noch weiter reduziert (komprimiert) werden kann. Völlig außer Acht gelassen wird dabei aber, wie viele Bilder geladen werden. Dies wäre jedoch umso wichtiger, da das HTTP-Protokoll nur das Laden von vier Ressourcen gleichzeitig vorsieht.

„HTML reduzieren“ und „CSS reduzieren“

Die Reduktion von HTML und CSS ist zwar richtig, jedoch können hier nur ein einstelliger Prozentbereich an Daten des Response gespart werden. Einerseits hat hier, wie oben bereits erläutert, die Latenz die tragende Rolle bei der Ladezeit, andererseits ist optimiertes HTML und CSS nur ein Tropfen auf dem heißen Stein, wenn zusätzlich noch Grafik- und Scriptdateien geladen werden, welche ohnehin ein Vielfaches an Dateigröße mit sich bringen.

„JavaScript reduzieren“

Im Gegensatz zu HTML- und CSS-Dateien können große Scriptbibliotheken einige hundert Kilobyte an Daten mit sich bringen. Daher ist der Ansatz, JavaScript zu reduzieren, zwar richtig, jedoch sollte intensiver der Fakt beleuchtet werden, dass hier eine große Scriptdatei besser wäre als viele kleine Scriptdateien (siehe Punkt „Bilder optimieren“)

„Above the Fold optimieren“

PageSpeed Insights spricht bei dem Optimierungsvorschlag von Ressourcen „Above the Fold“ davon, dass Inhalte (Stildefinitionen, Scripte und Grafiken) verzögert geladen werden sollen, wenn diese nicht unmittelbar im Bereich des Bildschirms auftauchen. Zwar kann durch die Einhaltung dieser Empfehlung ein Teil an Ressourcen gespart werden, jedoch ist die technische Umsetzung recht kompliziert und zeitraubend. Um die meisten Leistungsziele zu erfüllen, ist die Optimierung der Serveranfragen für den Inhalt „Above the Fold“ nicht erforderlich. Zusätzlich wird der Seitenbesucher nicht viel Zeit benötigen, um zu scrollen, und somit Inhalte „below the fold“ anzufordern.

Diese Gegebenheiten sollten auch bewertet werden

Um ein fundierteres Ergebnis zu liefern, sollte PageSpeed Insights auch weitere Faktoren berücksichtigen.

Drittanbieter-Inhalte nicht bewerten

Die Hinweise beziehen sich stets auf den Gesamtinhalt der Internetseite. Das scheint auf den ersten Blick vernünftig. Es mag paradox erscheinen, aber der Seitenbetreiber bzw. der Seitenentwickler hat oft nicht auf die Gesamte Website Einfluss. Dies gilt insbesondere für Bibliotheken und Apps von Drittanbietern, etwa

  • Einbindung von Wetter- oder Newstickern
  • Sharing-Buttons von Drittanbietern (z.B. Facebook)
  • Eingebettete Videos (z.B. YouTube)
  • Werbeanzeigen von Drittanbietern
  • Analyse-Scripte (z.B. Google Analytics)

Kurioserweise ist tatsächlich die hauseigene Analysesoftware oft ein Grund dafür, nicht die volle Punktzahl zu erreichen.

Unabhängige Verbesserungen anstreben

Unabhängig von den Messergebnissen von PageSpeed Insights empfehlen wir folgende Optimierungen.

Messergebnisse genau erfassen

Der oben zu sehende Screenshot stammt aus den Entwicklertools von Google Chrome. Jeder Anwender kann per Druck auf F12 dieses Tool nutzen, um genau zu analysieren, was passiert, wenn die Seite geladen wird. Anstatt blind den PageSpeed Insights-Ergebnissen zu glauben, ist ein Blick auf die Request- und Responsezeit einzelner Komponenten durchaus informativ, um neue Optimierungsansätze zu erhalten.

Zielsetzung verfeinern

Ein 100-Punkte-Wert bei Googles PageSpeed-Dienst ist nicht das Ziel der bestmöglichen Performanceoptimierung. Stattdessen sollte ein eigenes Ziel definiert werden. Dies kann einerseits daraus bestehen, bessere Request- und Response-Messwerte (s.o). als die Mitbewerber zu haben, andererseits sollte auch die Latenzzeit verringert werden (das ist der Punkt, den PageSpeed Insights nicht abdeckt). Dies kann etwa mit einem CDN (Content Delivery Network) geschehen.

Technische Parameter prüfen

Während PageSpeed Insights fast ausschließlich Software-Optimierungen bewertet, gibt es auch auf Seite der Hardware Verbesserungsansätze. So könnte man etwa, wie oben angeschnitten, ein CDN (Content Delivery Network) aufbauen, um die Inhalte besser und schneller zu liefern. Dies erfordert jedoch ein hohes technisches Verständnis und die Unterstützung der Software. Zusätzlich kann die Latenz auch mit dem Nachfolger des HTTP-Protokolls, HTTP2, verringert werden. Dies muss der Server jedoch umfangreich unterstützen.

Fazit

PageSpeed Insights ist ein interessantes und intelligentes Tool, welches jedoch allein keine Aussagekraft besitzt. Ähnlich wie bei Webseite-Bewertungsdiensten hat man hier das Problem, dass nicht der gesamte Bereich abgedeckt werden kann, um ein umfassendes und allgemein gültiges Messergebnis zu liefern. Kritisch betrachtet suggerieren derartige Tools, dass man mit der Behebung aller negativ ausgefallenen Testergebnisse ausgesorgt hat.

Wer darüber informiert ist, dass nur ein Teilbereich der Performance von PageSpeed Insights abgedeckt wird, hat Zugriff ein nützliches Stück Software, welches in das Portfolio jedes Entwicklers gehört – die nötige Neutralität und das technische Verständnis dazu jedoch vorausgesetzt.

 

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.