Ich war lange skeptisch, globale Browsernutzungs-Prozentzahlen zu zitieren, um die Nutzung von Browser-Features zu rechtfertigen. Es ist egal, wie die globale Nutzung eines Browsers ist, außer als nerdiges Geschwätz auf Cocktailpartys. Die relevante Nutzung ist, was die Nutzer auf Ihrer Website verwenden, und das kann von Website zu Website stark variieren.
Diese Idee, die tatsächliche Nutzung Ihrer tatsächlichen Website zu verfolgen, beschäftigt mich seit ein paar Tagen. Und es geht nicht nur um das typische "Ich kann CSS-Grid nicht verwenden, weil IE 11 immer noch 1,42% globale Nutzung hat", sondern darum, Metriken zu messen, die für Ihre Website wichtig sind, egal welche.
Performance-Metriken sind ein großes Thema. Wenn Sie Performance-Tests durchführen, handelt es sich oft um das, was Sie als synthetische Tests bezeichnen würden. Ein automatisierter Browser lädt Ihre Website und verfolgt, was er während des Ladens findet, wie die Zeitdauer eines Elements, die Größe der Assets, die Anzahl der Assets usw. Synthetische Informationen wie diese kommen mir in den Sinn, wenn ich viel Zeit mit Performance verbringe. „Ich wette, ich kann diese eine zusätzliche Anfrage loswerden", denke ich. „Ich wette, ich kann dieses Asset noch etwas weiter optimieren." Und die Performance-Tools, die wir verwenden, berichten uns diese Art von Daten leicht verfügbar. Wie groß ist unser JavaScript-Bundle? Was ist unser „Largest Contentful Paint"? Was ist unser Lighthouse-Performance-Score? Alles Dinge, die mit Performance zusammenhängen, aber nicht die tatsächliche Nutzererfahrung messen.
Lassen Sie das mal sacken.
Es gibt andere Analysen, die wir auf einer Website sammeln können, wie Nutzungsanalysen. Zum Beispiel könnten wir Google Analytics auf einer Website einfügen, ohne mehr zu tun, als den generischen Snippet zu installieren. Dies wird uns Dinge wie die beliebtesten Seiten, die Verweildauer der Nutzer auf der Website und die Länder, die den meisten Traffic liefern, mitteilen. Das sind echte Nutzeranalysen, aber es sind sehr generische analytische Informationen.
Wenn Sie auf Ihrer Website auf nützlichere Analysedaten hoffen, müssen Sie im Voraus etwas mehr nachdenken. Was möchten Sie wissen? Vielleicht möchten Sie wissen, wie oft Leute Feature X nutzen. Oder Sie möchten wissen, wie viele Dateien sie diese Woche hochgeladen haben. Oder wie viele Nachrichten sie gesendet haben. Oder wie oft sie auf den Stern-Button geklickt haben. Das sind Dinge, die Ihnen sagen, wie Ihre Website performt. Generisches Analytics-Tracking wird das nicht leisten; Sie müssen ein wenig JavaScript schreiben, um diese Dinge zu erfassen und zu berichten. Es erfordert etwas Aufwand, um die Analysen zu erhalten, die Ihnen wirklich wichtig sind.
Wenden Sie das nun auf Performance-Tools an.
Warum nicht Dinge messen, die für Ihre spezifische Website tatsächlich wichtig sind, anstatt generischer synthetischer Tests? Ein Aspekt davon ist RUM, also "Real User Monitoring". Anstatt eines einzelnen synthetischen Tests als Quelle für alle Performance-Tests auf Ihrer Website zu verwenden, verfolgen Sie echte Nutzer, die die Website tatsächlich auf ihren tatsächlichen Geräten nutzen. Das ergibt für mich viel Sinn, aber abgesehen von der Logik erschließt es einige wichtige Daten.
Zum Beispiel gehört zu den Web Core Vitals von Google, die bald die SEO unserer Seiten beeinflussen werden, eine Metrik namens First Input Delay (FID), und Sie müssen Daten über JavaScript¹ auf Ihrer Seite sammeln, um sie nutzen zu können.
Ein weiteres Web Core Vital ist "Largest Contentful Paint", ein faszinierender Versuch einer aussagekräftigeren Performancemetrik. Stellen Sie sich eine Metrik wie "Start-Rendering" oder den ersten Seitenanstrich vor. Ist das interessant? Irgendwie. Zumindest signalisiert es dem Nutzer, dass etwas passiert (wahrscheinlich). Doch dieses erste Rendering ist vielleicht nicht wirklich nützlicher Inhalt, wie die Schlagzeile und der Haupttext eines Nachrichtenartikels. Diese Metrik versucht also zu erraten, was dieser nützliche Inhalt wahrscheinlich ist, und misst diesen. Sehr clever.
Aber warum raten? Ich verstehe, warum Google raten muss. Sie müssen LCP auf unzähligen Websites messen und allgemein nützliche Messungen liefern. Aber auf Ihrer eigenen Website (wiederum, wo die fokussierten Analysen tatsächlich wichtig sind) können wir Performance-Tools sagen, welche Elemente uns wichtig sind und aufzeichnen, wann sie gerendert werden. Persönlich wäre mir wichtig, wann der Artikel selbst auf dieser Website gerendert wird. Mit SpeedCurves Hero Rendering Time könnte ich so etwas tun:
<main elementtiming="article"></main>
<!-- or focus on the top of the page, like the "hero" timing suggests -->
<header elementtiming="hero"></header>Jetzt messe ich, was für meine Website wichtig ist und nicht nur generische Zahlen.
Ähnlich ist FID gut und schön, aber warum nicht ein JavaScript-Ereignis auslösen, das Performance-Tools darüber informiert, wenn Dinge passieren, die für Ihre Website wichtig sind? Zum Beispiel würden wir das bei CodePen tun, wenn der Editor einsatzbereit ist. Das nennt man User Timing und es ist eine verdammte W3C-Spezifikation!
Editors.init();
performance.mark("Editors are initialized.");Diese Art von einige-Aufwand-erfordernden Analysen ist definitiv besser als der Standard. Sicher, ein Performance-Budget, das Sie warnt, wenn Sie über 200 KB JavaScript hinausgehen, ist großartig, aber ein Performance-Budget, das Sie warnt, wenn eine Kernfunktion Ihrer App bis 1,4 Sekunden nicht bereit ist, wenn Ihr Budget 1,1 Sekunden beträgt, ist weitaus wichtiger.
- Ich sage das, weil ich versucht habe, ein Diagramm der drei Web Core Vitals auf SpeedCurve zu erstellen, und Sie können FID nicht hinzufügen, es sei denn, Sie haben LUX laufen, was deren RUM-Ding ist. Puh, das waren viele Akronyme, sorry.
Das erinnert mich an eine Website, an der ich gearbeitet habe, bei der der Kunde darauf bestand, dass ich alles behebe, was die Performance-Websites als falsch an der Website befanden. Ich habe alles wie gewünscht behoben, und es hat die Zahlen verbessert ... aber es hat die Benutzererfahrung ruiniert und die Website schien langsamer zu laden (obwohl Lighthouse und andere sagten, sie sei jetzt schneller). Was der Benutzer sah und was die Bots sahen, war nicht dasselbe. Der Kunde hat mich dazu gebracht, die Bots glücklich zu machen, auf Kosten der tatsächlichen Benutzer.
Auch wenn ich zustimme, können wir globale Statistiken nicht ganz ignorieren. Sie erhalten beispielsweise möglicherweise nicht viele Firefox-Nutzer auf Website A, da diese stark auf Feature X angewiesen ist, das Fx nicht unterstützt. Ihre Statistiken werden Ihnen sagen, dass Sie sich weiterhin auf Feature X verlassen können, da Sie nicht viele Fx-Nutzer haben, aber Sie haben keine Fx-Nutzer, weil Sie X verwenden.
Indem wir auch die globalen Statistiken berücksichtigen, können wir ein besseres Bild davon bekommen, wo wir auch Zeit mit Verbesserungen verbringen könnten.
Aber wenn es darum geht, Dinge wie IE-Polyfills und alten Code zu entfernen, dann spielen globale Statistiken keine Rolle und Sie sollten sich absolut auf Ihre Website-spezifischen Statistiken verlassen, wie Sie sagen.