Ich hatte ein paar gute Performance-Links, die ein Loch in meiner Tasche brannten, also blogge ich sie wie ein guter kleiner Blogger.
Web Performance Recipes With Puppeteer
Puppeteer ist eine Node-Bibliothek zum Starten einer Kopie von Chrome "headless" (d. h. ohne Benutzeroberfläche) und zur Steuerung. Leute nutzen es für Dinge wie das Erstellen von Screenshots einer Website oder das Ausführen von Integrationstests. Sie können es sogar in einem Lambda ausführen.
Ein weiterer Anwendungsfall ist die Durchführung synthetischer (d. h. nicht auf echten Benutzern basierender) Performance-Tests, wie einige dieser neuen Web Core Vitals
Addy Osmani listet eine Reihe dieser „Rezepte“ zum Messen bestimmter Performance-Dinge in Puppeteer auf. Diese wären als Teil eines Build-Prozesses neben anderen Tests äußerst nützlich. Haben die Unit-Tests bestanden? Haben die Integrationstests bestanden? Haben die Accessibility-Tests bestanden? Haben die Performance-Metriken-Tests bestanden?
BrowserStack SpeedLab
BrowserStack hat ein Tool veröffentlicht, um Ihre Website zu messen und Ihnen einen Performance-Score zu geben.
Die Testergebnisse erhalten Sie sehr schnell, was cool ist. Ich kann sehen, wie nützlich solche Tools sind, um Gespräche mit Teams über die Verbesserung der Performance anzustoßen.
Aber… diese Zahl scheint ein wenig seltsam. Sie dokumentieren nicht genau, wie sie berechnet wird, aber sie scheint auf Dingen wie Time to First Byte (TTFB) und dem Page Load Event zu basieren, was keine besonders nützlichen Performance-Metriken sind.
Es ist nicht schlecht, dass dieses Tool existiert oder so, aber ich glaube nicht, dass es für Praktiker ist, die Performance-Arbeit leisten.
5 Common Mistakes Teams Make When Tracking Performance
Karolina Szczur von Calibre dokumentiert einige gängige Schwierigkeiten von Teams, wie zum Beispiel, dass ein Team echte Probleme von Rauschvariabilität unterscheiden kann.
Viele Menschen mit unterschiedlichen Hintergründen können Performance-Dashboards einsehen. Wenn man nicht weiß, was eine bedeutsame Änderung darstellt, die untersucht werden muss, kann dies zu Fehlalarmen, mangelndem Vertrauen in die Überwachung und zu Zyklen führen, die damit verbracht werden, nach Gründen für Performance-Rückgänge oder -Verbesserungen zu suchen, die nicht vorhanden sind.
Sind Ihre JavaScript-Long-Tasks frustrierend für Benutzer?
50ms. So lange dauert es, bis jede einzelne JavaScript-Aufgabe die Benutzererfahrung beeinträchtigt. Es lohnt sich, sie zu verfolgen und (idealerweise) zu beheben.
Wenn der Hauptthread des Browsers für mehr als 50 ms maximal ausgelastet ist, beginnt ein Benutzer zu bemerken, dass seine Klicks verzögert sind und das Scrollen der Seite ruckelnd und nicht reaktionsfähig wird. Akkus entladen sich schneller. Leute klicken wütend oder gehen woanders hin.
Hallo Chris,
Vielen Dank für Ihr Feedback.
Ich bin der Produktmanager, der an SpeedLab arbeitet. Unser Fokus lag darauf, Website-Geschwindigkeitstests auf echten Geräten und Browsern bereitzustellen, um die reale Benutzererfahrung zu messen.
Derzeit verlassen wir uns auf die Page Load-Metrik zur Berechnung von Scores unter Verwendung einer log-normalen Verteilungsfunktion. Für Desktop-Websites erhalten Seitenladezeiten unter 2100 ms auf einem Browser einen Score von 90 oder höher. Für mobile Websites erhalten Seitenladezeiten unter 1500 ms auf einem Gerät einen Score von 90 oder höher. Diese Schwellenwerte wurden auf der Grundlage des HTTP Archive-Datensatzes und nach Anpassungen für hohe Netzwerkgeschwindigkeiten in unserem Rechenzentrum gewählt. Jedes Gerät und jeder Browser erhält das gleiche Gewicht, um den gesamten Endscore für Mobilgeräte und Desktops zu berechnen.
Wir werden unser Scoring-Modell weiterhin auf der Grundlage nutzerzentrierterer Paint-Metriken wie FCP und LCP weiterentwickeln.