Speed Matters: Wie viele Pferdestärken Publisher nicht auf die Straße bringen.

Takeaways:

• 6% der Publisher-Domains machen einen optimierten Eindruck
• Je schlechter die Performance auf Google News, desto geringere Ladezeit (!=Kausalität)
• Bilder, Caching, Gzip und mergen/minifyen von CSS/JS hat den höchsten Impact zur Verbesserung der Ladezeiten
• Die durchschnittliche News-Startseite lädt 106 Ressourcen und hat mehr als 1,8MB

Geschwindigkeit ist wichtig. Nicht nur für eine gute User-Erfahrung, sondern auch nicht schädlich für ein gutes Ranking. Im Nachrichtengeschäft gilt es umso mehr. Der hohe Anteil mobiler Nachrichtenrezeption macht das deutlich.
Spannend also die Frage, wie schnell die Seiten sind. Objektive Geschwindigkeitsmessung ist ein schwieriges Feld. Ich persönlich gebe nicht viel auf „Die Seite lädt in X Sekunden“–Aussagen. Zu volatil ist das Ergebnis nach Endgerät, eigener Anbindung, Standort, Tageszeit. Wichtiger ist mir objektiv bestimmbare Kriterien zu messen. 90-95% der Ladezeitoptimierung liegt im Frontend. Hier kann ich also die Anzahl und Größe der übertragenen Objekte messen, CSS-Mengen, etc.

1.850 News-Domains in PageSpeed abgefragt

Google bietet hierfür sein PageSpeed-Tool an, dass einem einen kleinen Score zwischen 0 und 100 (höher=besser) errechnet und Optimierungsmaßnahmen (Verteilung, Komprimierung, Reduzierung) vorschlägt.
Fix also die News-Publisher aus der Datenbank geholt, der Page-Speed API vorgeworfen und nachgeschaut, was die so zurückmeldet.
1.856 bei Google News gelistete Publisher haben wir gemessen.

Im Mittel haben wir 74 Punkte gemessen, wobei 50% der Seiten mehr als 76 Punkte hatten. Die Standardabweichung liegt bei knapp 14 Punkten.

Größer als eine 3,5″-Floppy

Im Schnitt werden für den Aufruf der Startseite 106 unterschiedliche Ressourcen geladen (HTML-Dateien, Bilder, JavaScript, CSS, etc.). Für diese 106 Ressourcen werden insgesamt durchschnittlich 1,8 Megabyte geladen. Jeder Aufruf einer Domain, die in Google News gelistet wird ist also statistisch gesehen 20% größer als eine 3,5″–Floppy (Zumindest die 1,44 MB – Variante von 1987, 2.88er von 1991 sind mir nicht oft untergekommen…).
Im Schnitt werden 21 Java-Skripte und 7 CSS-Dateien geladen. Dass das nicht unbedingt wirtschaftlich ist, leuchtet jedem ein, der sich mal mit Performance-Optimierung beschäftigt hat.
Bevor wir in die Details springen noch der kurze Hinweis: Solche Tools sind immer eine erste Orientierung. Bei der einen oder anderen Domain schlägt so ein Tool völlig in die leere, jeder Browser misst anders und die tollste Optimierung bringt nichts, wenn der Server nur mit 5 Sekunden Verzögerung ausliefern kann.

6% der Domains sind optimiert

Wenn wir uns die Score–Verteilung ansehen, sehen wir folgendes Bild:

Verteilung der Publisher nach Page Speed Score

Bei einem Score über 90 kommen die anstrengenden letzten 20% der Optimierung, die 80% des Aufwands ausmachen. Hier ist echtes Feintuning angesagt und häufig rechtfertigen die Mehrwerte hier die Aufwände nicht mehr. Diese Scores erreicht man in der Regel auch nur, wenn man entweder eine sehr einfache Seite aus den 90er Jahren hat und sich damals Gedanken um Performance gemacht hat (was war nochmal ISDN?) — oder wenn man aktiv zum Thema Performance gearbeitet hat.

Wer darunter ist, sieht häufig nicht die Notwendigkeit. Bei einem Score von unter 70 gibt es zwei Möglichkeiten:

1. Ein Messfehler (kann mal passieren)
2. Fehlende Ressourcen zur Optimierung / Fehlendes Problembewusstsein

Wie wir sehen betrifft dieses Problem ~60% der deutschen Google News-Publisher.

Beispiele:
Schnell unterwegs sind Beispielsweise Netzwelt oder Focus und Chip.de. Die anderen Seiten mit einem Score über 90 sind weniger Prominent.
Unter den langsamsten Domains befinden sich bundestag.de, pressebox.de und rbb-online.de.

Im Graphen sehen wir, dass der Page Speed mit abnehmendem Erfolg eines Publishers auf Google News im Trend ebenfalls abnimmt. Hier gibt es eine gefühlte Korrelation (statistische Auswertung hab ich mir gespart). Allerdings ist das logisch und heißt nicht unbedingt, dass die erfolgreichen Publisher erfolgreich sind, weil sie eine schnelle Seite haben. Die Logik funktioniert eher umgekehrt. Erfolgreich sind vor allem die großen Publisher auf Google News. Diese haben aber auch ausreichend Technikressourcen und arbeiten vermutlich stärker an der Seite.

PageSpeedScore nach Google News Erfolg

Maßnahmen, die Google zur Ladezeitoptimierung empfiehlt

Welche konkreten Verbesserungsvorschläge macht Google Page Speed jetzt den Publishern?

Sehen wir uns an, welche Maßnahmen am Häufigsten einer Domain empfohlen werden:

• Reduce request serialization (91% der Domains)
• Specify a Vary: Accept-Encoding header (89% der Domains)
• Minify HTML (88% der Domains)
• Eliminate unnecessary reflows (87% der Domains)

Am Ende der Liste stehen:

• Avoid bad requests (11% der Domains)
• Defer parsing of JavaScript (11% der Domains)
• Minimize request size (8% der Domains)
• Serve resources from a consistent URL (0% der Domains)
• Specify image dimensions (0% der Domains)

Google PageSpeed gibt uns allerdings noch einen weiteren Hinweis: RuleImpact. Damit beschreibt Google einen relativen Wert, welche dieser Empfehlungen einer Domain mehr Geschwindigkeitssteigerung bei Umsetzung verspricht. Sehen wir uns hier das Bild an (Häufigkeit der Nennung mal Impact), sehen wir eine etwas andere Verteilung.

Die Punkte mit dem meisten Impact sind:

• Leverage browser caching
• Optimize images
• Defer parsing of JavaScript
• Enable compression
• Minify JavaScript