Die Wahrheit über Speed Scores (Googles Core Web Vitals)

Warum Google Pagespeed‑, Pingdom- und GTmetrix-Scores keine Rolle spielen!

Hören Sie auf, auf die­se dum­men Page Speed Scores und Tests zu hören (wenn Sie nicht wis­sen, was Sie tun)!

Ich habe die­sen Leitfaden geschrie­ben, um zu ver­mei­den, dass ich mich bei nai­ven Kunden immer wie­der selbst wie­der­ho­len muss. Hoffentlich hilft er auch ande­ren Entwicklern/Admins, die sich mit Neulingen über Geschwindigkeitsoptimierung strei­ten. (Das ist so ähn­lich, wie wenn sich Leute mit ihrem Arzt strei­ten, weil sie etwas auf NetDoktor gele­sen haben).

Hier ist die end­gül­ti­ge Erklärung, war­um Sie auf­hö­ren müs­sen, wegen der Seitenwerte para­no­id zu sein. (Und hören Sie auch auf, sich mit Entwicklern und Systemadministratoren zu strei­ten, die mehr wis­sen als Sie!

• Seitenscore’s sind unwichtig!
• Seitentimings sind die wich­tigs­ten Werte! (TTFB & Paint Times)
• Waterfall: Above the Fold Items sind wichtig!
• Waterfall: Items die am Ende sind, sind unwichtig!

1. Sie wissen nicht, wie man einen Geschwindigkeitstest liest.

Ich wür­de wet­ten, dass die meis­ten Leute, die sich über die Geschwindigkeitsergebnisse auf­re­gen, nicht ein­mal pro­fes­sio­nel­le Web-Entwickler oder Programmierer sind. Es gibt einen Grund, war­um teu­re Werkzeuge und Instrumente in Krankenhäusern nur von zer­ti­fi­zier­ten Ärzten ver­wen­det wer­den dür­fen. Es ist, weil sie wis­sen, was sie tun. Sie wis­sen, auf wel­che Metriken sie ach­ten müs­sen und wel­che sie igno­rie­ren kön­nen. Warum las­sen sie nicht irgend­ei­ne belie­bi­ge Person einen Blick dar­auf wer­fen? Weil die­se zufäl­li­ge Person kei­ne Ahnung hät­te, wie es funk­tio­niert, was es misst und ob jedes Ergebnis schlecht oder gut ist. Sie wür­den ein­fach in Panik gera­ten und auf jeden visuellen/akustischen Hinweis, den das Gerät gibt, überreagieren!

Einfache Fragen, um zu wis­sen, ob Sie für einen Geschwindigkeitstest qua­li­fi­ziert sind:

• Wissen Sie, was TTFB ist?
• Wissen Sie, was “First Paint” bedeutet?
• Wissen Sie, wel­che Elemente im Waterfall am wich­tigs­ten sind?
• Wie kön­nen Sie fest­stel­len, ob ein CDN Ihre Website hilft oder schadet?
• Was ist HTTP/2, und was ist sein Vorteil?
• Woran erken­nen Sie, ob Ihre Bilder aus­rei­chend kom­pri­miert sind?
• Warum soll­ten Sie 3rd-Party-Anfragen ignorieren?
• Wie weit soll­te der Geschwindigkeitstest-Server von Ihrem Webserver ent­fernt sein?

Wenn Sie nichts davon ver­ste­hen, sind Sie abso­lut NICHT qua­li­fi­ziert, einen Geschwindigkeitstest zu lesen…und defi­ni­tiv nicht qua­li­fi­ziert, mit Ihrem Entwickler oder Geschwindigkeitsberater dar­über zu strei­ten, wel­che Dinge opti­miert wer­den sollten.

2. Geschwindigkeitstests sind für die OPTIMIERUNG von (GESCHWINDIGKEITS) SCORES, statt für die BENUTZER.

Die Falle Nr. 1 bei Geschwindigkeitstests.

Es geht dar­um, dass Sie Ihre Website für Geschwindigkeitstests opti­mie­ren und nicht für die tat­säch­li­chen Benutzer. Das ist eine schreck­li­che Entscheidung! Es ist das Äquivalent dazu, Inhalte für SEO zu schrei­ben, anstatt Inhalte für Menschen zu schrei­ben. Man könn­te mei­nen, dass es logisch und har­mo­nisch ist, bei­des anzu­spre­chen, aber das ist in der Realität nicht immer der Fall. Das Gleiche gilt für Geschwindigkeitstests und Benutzererfahrung. Was für einen Geschwindigkeitstest-Crawler "schnell und nütz­lich" ist, muss nicht unbe­dingt "schnell und nütz­lich" für einen tat­säch­li­chen mensch­li­chen Besucher sein.

Google

Das liegt an der ein­fa­chen Tatsache, dass die Optimierung für den Benutzer bedeu­tet, eine gewis­se Benutzererfahrung in der schnellst­mög­li­chen Ladezeit zu lie­fern. Während die Optimierung für Geschwindigkeitstests bedeu­tet, so WENIG wie mög­lich in der schnellst­mög­li­chen Ladezeit zu lie­fern. Das ist der Grund, war­um es so kniff­lig wird. Um ein bestimm­tes Benutzererlebnis zu schaf­fen, müs­sen vie­le bestimm­te Assets in einer bestimm­ten Ladereihenfolge gela­den wer­den. Aber die auto­ma­ti­sier­ten Geschwindigkeitstests wis­sen das nicht, also emp­feh­len sie ein­fach, so vie­le Bytes und so vie­le Anfragen wie mög­lich herauszuhacken.

Sie wis­sen nicht (oder kön­nen nicht berück­sich­ti­gen), was Sie wirk­lich brau­chen, oder was sich direkt auf Ihr Benutzererlebnis auswirkt.

Eine ein­fa­che Frage, um zu wis­sen, ob Sie die Geschwindigkeitswerte zu hoch einschätzen:

• Was bevor­zu­gen Sie? Schnelles Laden der Seite und schreck­li­che Seitenbewertung ODER lang­sa­mes Laden der Seite, aber eine groß­ar­ti­ge Seitenbewertung?
• Stört es Sie, wenn die Website Ihres Konkurrenten lang­sa­mer lädt als Ihre, aber einen höhe­ren Page Score hat?
• Glauben Sie wirk­lich, dass es wich­tig ist, einen 100/100 A+ Page Score zu haben?
• Glauben Sie wirk­lich, dass ein hoher Page Score bedeu­tet, dass Ihre Website schnell ist?

Ob Sie es glau­ben oder nicht, es gibt nur eine sehr gerin­ge Korrelation zwi­schen einer hohen Seitenbewertung und der Seitenladezeit. Schauen Sie sich ruhig vie­le belieb­te Websites da drau­ßen an und über­zeu­gen Sie sich selbst.

3. Geschwindigkeitstests berücksichtigen keine spezifischen Bedürfnisse der Website.

Jede Website ist anders!

Nehmen wir an, ein Auto fährt mit 500 Kilo Gepäck und ein ande­res Auto fährt mit 50 Kilo Gepäck. Trägt das ers­te Auto wirk­lich zu viel Gewicht? Wir wis­sen es nicht! Was wäre, wenn das ers­te Auto nur zum Nachbarhaus fah­ren wür­de und das zwei­te Auto zum Camping? Verstehen Sie, was ich meine?

Was ist, wenn der Speedtest sagt, dass Ihre Website-Bilder im Vergleich zu einer ande­ren Website zu schwer sind? Ist das gut oder schlecht? Nun, das kommt dar­auf an! Wenn es sich bei Ihrer Website um einen E‑Commerce-Shop oder ein Fotografie-Portfolio han­delt, wol­len Sie wahr­schein­lich grö­ße­re und hoch­wer­ti­ge­re Bilder! Wenn Ihre Seite ein ein­fa­cher Text-Blog ist, dann wol­len Sie viel­leicht klei­ne­re Bilder.

Sie kön­nen nicht zulas­sen, dass ein (dum­mes) auto­ma­ti­sches Tool die­se Dinge beur­teilt, wenn es denn Sinn dafür nicht hat, was Ihre Seite tut und wie sie sich von ande­ren Seiten unter­schei­det. Es beur­teilt alle Seiten nach einem (will­kür­li­chen) Standard, ohne die spe­zi­fi­schen Bedürfnisse jeder ein­zel­nen zu berück­sich­ti­gen. Die Idee ist fol­gen­de: was für eine Site "schlecht" sein mag, kann für eine ande­re tat­säch­lich "gut" oder "beab­sich­tigt" sein.

Beispiele für gän­gi­ge Vorschläge für Geschwindigkeitstests (und war­um sie feh­ler­haft sind):

• Kombinieren von CSS/JS, um Anfragen zu redu­zie­ren – kann das Laden der Seite tat­säch­lich ver­lang­sa­men und/oder das Design/die Funktion der Website beeinträchtigen!
• Bilder stär­ker kom­pri­mie­ren, um Platz zu spa­ren – redu­ziert die Bildqualität und wird nicht für Websites emp­foh­len, die qua­li­ta­tiv hoch­wer­ti­ge Bilder benötigen!
• Lazy-Load-Bilder, um das Laden der Seite zu beschleu­ni­gen – kann der UX scha­den, indem es die Fähigkeit zum schnel­len Scrollen behin­dert! Es muss gesagt wer­den, dass ver­zö­ger­tes Laden lang­sa­mer ist als normales!
• Langsame Gesamtladezeit – das soll­te kei­ne Rolle spie­len, da Benutzer nicht alles sofort laden müs­sen, son­dern nur die kri­ti­schen Elemente oder Elemente in der Nähe des obe­ren Bereichs der Seite!

4. Geschwindigkeitstests können Ihnen nicht sagen, was Ihre Geschwindigkeit am meisten beeinflusst.

Geschwindigkeitstests machen oft eine gro­ße Sache aus Dingen, die kei­nen Einfluss auf die Geschwindigkeit haben.

Sie geben Ihnen ein­fach eine rie­si­ge (und schein­bar) umfas­sen­de Liste von Checklisten und TO-DO's. Aber sie sagen Ihnen nicht, war­um die­se Dinge wich­tig sind. Viele der Dinge, die gemes­sen wer­den, wir­ken sich nicht wirk­lich auf Ihre Geschwindigkeit aus. Es sind nur zufäl­li­ge Optimierungen, die das Benutzererlebnis ver­bes­sern kön­nen (oder auch nicht)… sehr verwirrend!

Warum sind Geschwindigkeitstests nicht in der Lage, Ihnen zu sagen, was wich­tig ist?

Das liegt dar­an, dass sie kom­plett auto­ma­ti­siert sind und die Dinge nicht so beur­tei­len kön­nen wie ein Mensch (zumin­dest noch nicht). Sie gewich­ten die Metriken nicht abhän­gig von der Seite. Sie ver­ste­hen nicht, dass bild­be­zo­ge­ne Optimierungen auf bild­las­ti­gen Seiten mehr Gewicht haben soll­ten. Und dass CSS-bezo­ge­ne Optimierungen auf CSS-las­ti­gen Seiten mehr Gewicht haben soll­ten. Das kön­nen sie nicht berück­sich­ti­gen, also gewich­ten sie die­se Metriken für jede Seite gleich.

Eine CSS-Datei mit 500 KB Übergewicht im Vergleich zu einem Bild mit 5 KB Übergewicht zieht immer noch die glei­che Anzahl von Score Punkten ab.
10 Bilder, die jeweils mit 1 KB über­la­den sind, sen­ken Ihre Punktzahl mehr als Ihr CSS mit 30 KB Leerraum.

Sehen Sie, was ich mei­ne? Die Tests sind feh­ler­haft! Ich habe nicht jedes mög­li­che Szenario erklärt, in dem dies der Fall ist, und ich wer­de es auch nicht tun. Ich hof­fe, Sie erspa­ren uns bei­den die Zeit (und ver­trau­en mir einfach).

Geschwindigkeitstests berück­sich­ti­gen nicht, wann (all­ge­mei­ne) Regeln gebro­chen wer­den sollten.

Zum Beispiel die blö­de Beschwerde über Elemente, die nicht im Browser-Cache sind oder zu kur­ze Verfallszeiten haben. YES! Einige die­ser Elemente SOLLEN so sein. Einige Elemente SOLLEN nicht gecached wer­den und haben kur­ze Verfallszeiten, um bestimm­te Inhalte immer aktu­ell zu halten.

Render-blo­cking CSS – Ich wer­de das nächs­te Mal, wenn ich die­se Beschwerde sehe, ein Auto umdre­hen. CSS SOLLTE Render-Blocking sein. Wisst ihr, was pas­siert, wenn ihr CSS nicht render-blockiert?…Sie bekom­men FOUT/FOUC (Flash of unsty­led Text/Content) Probleme! Glauben Sie mir. Das ist Absicht!

5. Geschwindigkeitstests sind fehlerhaft.

Ja, sie sind feh­ler­haft und vie­le Benutzer wis­sen es nicht ein­mal! Sie geben Neulingen ein schlech­tes Gewissen wegen Dingen, die sie nicht ändern kön­nen oder soll­ten. Ich wer­de im Folgenden eini­ge Beispiele auflisten:

Veraltete Empfehlungen

Geschwindigkeitstests berück­sich­ti­gen immer noch nicht rich­tig die moder­nen Webserver-Technologien. Ich sehe immer noch vie­le Empfehlungen, die mit älte­rer Webserver-Technologie schnel­ler waren, aber mit heu­ti­ger Webserver-Technologie tat­säch­lich lang­sa­mer sind. Dinge wie die Empfehlung von GZIP, wenn Brotli ver­wen­det wird (zu Ihrer Information: Brotli ist bes­ser als Gzip), oder die Empfehlung, HTTP-Anfragen zu redu­zie­ren, wenn das HTTP/2‑Protokoll par­al­le­le Anfragen erlaubt!

Bestrafung für 3rd-Party-Anfragen

Ich has­se es abso­lut, wenn Geschwindigkeitstests auf die lang­sa­me Ladezeit, den feh­len­den Cache-Ablauf oder die Verschlüsselung für irgend­ei­ne von außen gela­de­ne Anfrage hin­wei­sen. Diese Elemente wer­den von einem ANDEREN SERVER gela­den, über den Sie kei­ne Kontrolle haben. Es ist nicht Ihre Schuld und Geschwindigkeitstests soll­ten eine ent­spre­chen­de Aussage geben. Und nur zu Ihrer Information: Einige extern gela­de­ne Anfragen wer­den nicht gecached oder ander­wei­tig "opti­miert", und das aus gutem Grund!

6. Fast alle Geschwindigkeitstests scheitern am AUGENTEST!

Was ist der Sehtest? Es ist im Grunde ein Test der Website für sich selbst mit Ihren eige­nen Augen. Wenn die Seite visu­ell schnell lädt, ist sie in Ordnung! Sie brau­chen sich kei­ne Gedanken über die "Gesamtladezeit" zu machen, denn die Dinge, die im Hintergrund gela­den wer­den, beein­träch­ti­gen Ihr Benutzererlebnis nicht wirklich.

Es soll­te der aller­ers­te Test der Seitengeschwindigkeit sein, den Sie durch­füh­ren. Und als nächs­tes soll­ten Sie die Entwickler-Tools Ihres Browsers nut­zen, um zu sehen, wie schnell alles in Ihrem Browser tat­säch­lich gela­den wird. Das ist näm­lich die Realität, näher an Ihren Besuchern kön­nen Sie nicht dran sein.

Sagen Sie mir, was für eine Seite Sie lie­ber hätten…eine, die in 3 Sekunden voll­stän­dig lädt…oder eine, die in 6 Sekunden voll­stän­dig lädt? (beant­wor­ten Sie die­se Frage, bevor Sie weitermachen)

• Was wäre, wenn ich Ihnen sagen wür­de, dass die 3‑Sekunden-Seite kom­plett leer ist und erst bei der 2,8‑Sekunden-Marke ger­en­dert wird, wäh­rend die 6‑Sekunden-Seite sofort erscheint und dann still­schwei­gend die weni­ger wich­ti­gen Dinge im Hintergrund lädt?
• Falls es nicht offen­sicht­lich ist, wür­de ich jeden Tag in der Woche die 6‑Sekunden-Seite wäh­len. Und das wür­den auch alle gro­ßen Fortune-500-Unternehmen tun… Tatsächlich brau­chen vie­le von ihnen meh­re­re Sekunden, um voll­stän­dig zu laden (obwohl sie visu­ell fast sofort erscheinen)!

Das ist es wovon ich spre­che. Viele Geschwindigkeitstests berück­sich­ti­gen das nicht. Und selbst wenn sie wich­ti­ge Metriken wie anfäng­li­che Rendering-Zeiten auf­lis­ten, wis­sen vie­le Benutzer nicht, wor­auf es ankommt und wor­auf sie ach­ten soll­ten! Alles, was sie inter­es­siert, ist die­se blö­de TOTAL LOAD TIME-Zahl (manch­mal beglei­tet von einer erschre­cken­den Warnmeldung).

7. Gängige Mythen und deren Widerlegung.

Wie immer kom­men Kunden mit logi­schen Annahmen und Fragen:

"Eine schnell laden­de Website oder ein hoher Speed-Score ist wich­tig für SEO."
Nicht wirk­lich. Sofern Ihre Website nicht super duper lang­sam ist, ist die­ser Spruch so gut wie falsch; es ist nicht ein­mal ein Mythos. Sie kön­nen es selbst über­prü­fen, indem Sie die Top-10-Ergebnisse für belie­bi­ge Suchbegriffe unter­su­chen. Es ist nicht unge­wöhn­lich, dass die Top-Ergebnisse 3–5 Sekunden zum Laden brau­chen (laut Page Speed Tests).

Abgesehen davon kann eine schnel­le Website das Nutzerengagement und die Conversions ver­bes­sern, und ich glau­be, dass dies den SEO-Rankings etwas hilft. Unabhängig davon ist Geschwindigkeit groß­ar­tig für Conversions!

"Man kann kei­ne gute/schnelle Website haben, ohne bei den Page Scores eine Eins zu bekommen!"
Sagt wer? Versuchen Sie, vie­le der popu­lärs­ten Websites, die Sie ken­nen, auf­zu­ru­fen und sehen Sie selbst, wie sie abschnei­den. Probieren Sie sogar die Webseiten von Google mit ihrem eige­nen GPI-Tool aus.

"Wenn die Geschwindigkeitswerte kei­ne Rolle spie­len, war­um gibt es sie dann?"
Sie exis­tie­ren als hilf­rei­che Checkliste für die­je­ni­gen, die wis­sen, wie sie zu lesen sind. Einige Dinge sind wich­tig, ande­re nicht.

"Warum ist die Website mei­nes Konkurrenten schnel­ler und erzielt höhe­re Punktzahlen als meine?"
Das kann vie­le Gründe haben. Viele haben einen schnel­le­ren Webserver, oder eine effi­zi­en­te­re Programmierung, oder weni­ger Plugins, oder weni­ger laden­de Assets, oder weni­ger laden­de 3rd-Party-Assets. Nur weil Sie ein Cache-Plugin instal­liert oder einen Experten für Geschwindigkeitsoptimierung enga­giert haben, ist das kei­ne Garantie dafür, dass Ihre Website bes­ser ist als die der Konkurrenz.

"Aber am ande­ren Tag habe ich ein ande­res Plugin instal­liert oder mit einer ande­ren Person zusam­men­ge­ar­bei­tet, die mei­nen Website-Score auf 100/100 erhöht hat."
Ja, es ist mög­lich, 100/100 zu errei­chen, wenn Sie sich um nichts ande­res als den Score küm­mern, aber Sie könn­ten dabei unbe­ab­sich­tigt das Laden Ihrer Seite ver­lang­sa­men oder die Benutzererfahrung behin­dern. Am Ende des Tages sind die­se Seiten-Score-Empfehlungen ein­fach EMPFEHLUNGEN… sie sind kei­ne Anleitung, die man für jedes Szenario befol­gen sollte.

"ES IST MIR EGAL, WAS SIE SAGEN! Machen Sie mei­ne Seite schnell und mit A+ 100/100 Score!"
Klar. Löschen Sie ein­fach alle Plugins, ver­wen­den Sie ein ein­fa­ches Theme. Haben Sie nicht mehr als 10 Bilder. Verwenden Sie kein Google Analytics oder Google Webfonts.

"Aber die­se Geschwindigkeitstests sind so beängs­ti­gend! Woher weiß ich, wel­che Dinge ich repa­rie­ren muss und wie ich sie repariere?"
Es könn­te hel­fen, sich die Zeit zu neh­men, zu lesen und zu ler­nen, wie alles funk­tio­niert. Vielleicht arbei­ten Sie ein paar Jahre lang als Webentwickler. Oder Sie könn­ten jeman­den ein­stel­len, der mehr Erfahrung hat als Sie.