Learnings From a WebPageTest Session on CSS-Tricks

Ich habe mich neulich mit Tim Kadlec von WebPageTest getroffen, um ein wenig Performance-Tests auf CSS-Tricks durchzuführen. Im Wesentlichen das Tool benutzen, herumstöbern und Performance-Schwachstellen identifizieren, an denen wir arbeiten können. Du kannst das Video gleich hier auf der Seite ansehen oder über deren Twitch-Kanal, was ein Abonnement für weitere Performance-Untersuchungen wie diese wert ist.

Web-Performance-Arbeit ist zweigeteilt

Schritt 1) Dinge messen & Probleme erkunden
Schritt 2) Es beheben

Tim und ich haben durch das erstaunliche Werkzeug, das WebPageTest ist, viel von Schritt 1 getan. Ich habe mir Notizen gemacht, während wir herumgestöbert haben. Wir haben eine Reihe von Problembereichen gefunden, einige ziemlich große! Natürlich konnte ich sie nach all dem nicht aus dem Kopf bekommen, also musste ich in Aktion treten und die Schritt 2-Sachen so schnell wie möglich erledigen, und ich freue mich zu berichten, dass ich die meisten davon erledigt und Verbesserungen gesehen habe. Lasst uns eintauchen!

Identifiziertes Problem #1) Schlechte LCP

Largest Contentful Paint (LCP) ist einer der Core Web Vitals (CWV), die gerade alle genau beobachten, da Google uns sagt, dass es ein SEO-Faktor ist. Mein LCP lag bei 3,993s, was nicht gerade gut ist.

Ich habe von Tim gelernt, dass es ideal ist, wenn der First Contentful Paint (FCP) den LCP *enthält*. Wir konnten durch WebPageTest sehen, dass dies nicht der Fall war.

Zu behebende Dinge

• Stellen Sie sicher, dass der LCP-Bereich, der letztendlich ein großes Bild war, richtig optimiert ist, ein responsives srcset hat und über ein CDN gehostet wird. All diese Dinge schlugen bei diesem speziellen Bild fehl, obwohl sie anderswo funktionierten.
• Das LCP-Bild hatte loading="lazy", was wir gerade gelernt haben, kein guter Ort dafür ist.

Behebungstechnik und Lernerfahrungen

• Die gesamte ordnungsgemäße Bildbehandlung war vorhanden, aber aus welchem Grund auch immer funktionierte sie nicht für .gif-Dateien, was das Bild am Tag des Tests war. Wir sollten wahrscheinlich sowieso keine .gif-Dateien für diesen Bereich verwenden.
• Schalten Sie das Lazy Loading des LCP-Bildes aus. Dies ist ein WordPress-Vorschaubild. Ich musste im Wesentlichen <?php the_post_thumbnail('', array('loading' => 'eager')); ?> verwenden. Wenn es sich um ein Inline-Bild gehandelt hätte, hätte ich <img data-no-lazy="1" ... /> verwendet, was WordPress mitteilt, was es wissen muss.

Identifiziertes Problem #2) Lücke zwischen erstem Byte und Renderbeginn

Tim sah dies sofort als ein ziemlich offensichtliches Problem.

Im obigen Wasserfall (hier ist ein super detaillierter Artikel über das Lesen von Wasserfalldiagrammen von Matt Hobbs) können Sie sehen, dass das HTML etwa 0,5 Sekunden lang ankommt, aber der Renderbeginn (was die Leute sehen, die große grüne Linie) erst bei etwa 2,9 Sekunden beginnt. Das ist viel zu lang.

Das Diagramm identifiziert das Problem auch mit einer gelben Linie. Ich habe auf eine externe CSS-Datei verlinkt, die dann zu meinen eigenen CSS-Dateien *weiterleitet*, die benutzerdefinierte Schriftarten enthalten. Diese Weiterleitung kostet Zeit, und wie wir herausfanden, nicht nur Ladezeit für die erste Seite, sondern *jede einzelne Seitenladung, sogar gecachte* Seitenladungen.

Zu behebende Dinge

• Entfernen Sie die CSS-Dateiumleitung.
• Schriftarten selbst hosten.

Behebungstechnik und Lernerfahrungen

• Ich habe mir sowieso einige neue Schriftarten angesehen. Ich habe vor nicht allzu langer Zeit festgestellt, dass ich die Lizenzinnovation von Mass-Driver (preislich nach Anzahl der Mitarbeiter) wirklich liebe, aber ich liebe ebenso MD Primer, also habe ich sie gekauft. Für den Fließtext bin ich bei einer angenehmen Serifenschrift mit Blanco geblieben, die dankbarerweise sehr schön optimierte RIBBI¹-Versionen enthielt. Nächstes Mal schwöre ich, dass ich eine variable Schriftart finden werde, aber hey, manchmal muss man seinem Herzen folgen. Ich habe diese gekauft und hoste die Schriftdateien jetzt selbst.
• Verwenden Sie @font-face direkt in meinem eigenen CSS, ohne Weiterleitungen. Verwende auch font-display: swap;, aber ich muss noch etwas mehr an dieser Lade-Technik arbeiten. Ich kann es kaum erwarten, dass size-adjust verfügbar ist.

Nach erneuter Prüfung mit der Änderung können Sie auf einer großen Artikelseite sehen, dass der Renderbeginn auf einer 4G-Verbindung volle 2 Sekunden schneller ist

Identifiziertes Problem #3) CLS im Grid Guide ist schlecht

Tim hatte einen raffinierten Trick auf Lager, um Cumulative Layout Shift (CLS) auf Seiten zu messen. Sie können WebPageTest anweisen, die Seite für Sie herunterzuscrollen. Das ist wichtig für etwas wie CLS, da Layout-Verschiebungen aufgrund des Scrollens auftreten können.

Sehen Sie sich diesen Artikel über CLS und WebPageTest an.

Der Trick besteht darin, eine erweiterte Einstellung zu verwenden, um beim Test benutzerdefiniertes JavaScript auf die Seite einzufügen

Zu diesem Zeitpunkt testeten wir nicht die Homepage, sondern gezielt eine sehr wichtige Seite: unseren Complete Guide to Grid. Mit dieser Einstellung sehen Sie, dass die CWVs in einem viel schlechteren Zustand sind

Ich weiß nicht genau, was ich vom LCP halten soll. Dieser wird durch das größte Bild, das zufällig weit unten auf der Seite liegt, ausgelöst.

Der CLS ist für mich besorgniserregender, denn *jede* sich verschiebende Layout ist für Benutzer immer störend. Sehen Sie all diese gepunkteten orangefarbenen Linien? Das ist CLS, das passiert

Zu behebende Dinge

• CLS ist schlecht wegen per Lazy Loading geladenen Bildern, die das Layout verschieben.

Behebungstechnik und Lernerfahrungen

• Ich weiß es nicht! All diese Bilder sind Inline-<img loading="lazy" ...>-Elemente. Ich verstehe, dass Lazy Loading CLS verursachen *könnte*, aber diese Bilder haben ordnungsgemäße width und height Attribute, was angeblich den exakten Platz reserviert, der für das Bild benötigt wird (auch wenn es flüssig ist, dank des Seitenverhältnisses), noch bevor es geladen wird. Also... was ist los? Liegt es daran, dass es SVGs sind?

Wenn jemand die Antwort weiß, kann er sich gerne bei mir melden. So ist die Natur der Performance-Arbeit, wie ich finde. Es ist eine Mischung aus einfachen Gewinnen durch alberne Fehler, kleinen Kämpfen, die man führen und gewinnen kann, größeren Kämpfen, die manchmal äußere Einflüsse beinhalten und schwerer zu gewinnen sind, und mysteriösen Unbekannten, deren Heilung Zeit braucht. Glücklicherweise haben wir Werkzeuge wie WebPageTest, die uns die echten Geschichten erzählen, die auf unserer Website passieren, und uns die Einblicke geben, die wir brauchen, um diese Performance-Kämpfe zu führen.

---