Chrome may identify sites that typically load fast or slow for users - Chrome will die typische Ladegeschwindigkeit von Websites anzeigen
Moving towards a faster web
blog.chromium.orgSpeed has been one of Chrome’s core principles since the beginning - we’re constantly working to give users an experience that is instant a...
Wer eine Website hat, der kennt das Thema: Lädt die Seite schnell oder ist das alles lahm? Erst recht ist das Problem allen Nutzern gut bekannt. Langsame Seiten sind anstrengend. Die technischen Gründe für die Langsamkeit mögen manchmal verständlich sein. Aber es nervt.
Der Chrome-Browser will dieses Thema in Zukunft noch "etwas verschärfen". Indem Websites, die langsam laden, markiert werden sollen.
.
Moving towards a faster web
https://blog.chromium.org/2019/11/moving-towards-faster-web.html
.
> In the future, Chrome may identify sites that typically load fast or slow for users with clear badging.
Chrome kann Websites identifizieren bzw. entsprechend angepaßt darstellen, die typischerweise schnell oder langsam laden. Das soll sich also nicht auf den aktuellen Ladevorgang beziehen, den bekommt der Nutzer ja direkt mit. Stattdessen sollen historische Daten ausgewertet werden. Wobei für mich unklar ist, ob diese historischen Daten von früheren Chrome-Besuchern oder vom Spidern der Website durch Suchmaschinenrobots stammen.
Wie das dargestellt werden soll, ist noch unklar. Da sollen erst noch diverse Tests durchgeführt werden, um die verständlichste Form zu finden.
Seiten sollen daraufhin überprüft werden, ob sie von ihrer Erstellungstechnik her im Allgemeinen langsamer sind. Eventuell wird das so erweitert, daß relativ zu dem Gerät des Nutzers ermittelt wird, ob die Seite für diesen Nutzer langsam ist. Die Wirkung: Dieselbe Seite wird für einige Nutzer als "langsame Seite" angezeigt, für andere Nutzer als "schnelle Seite".
Das kann an verschiedenen Stellen der Chrome-Oberfläche auftauchen: Etwa bei der Ladefortschrittsleiste und bei Kontextmenüs von Links. Dort könnte die typische Seitengeschwindigkeit sofort angezeigt werden, so daß man vor dem Aufrufen des Links sieht, wie lange das Laden der Seite ungefähr dauern wird.
Der Beitrag zeigt zwei Screenshots: Ein grüner Fortschrittsbalken für eine schnell ladende Seite. Ein blauer Balken für eine langsam ladende Seite. Ferner beim "Loading" der Hinweis:
> Usually loads slow
mit einem roten Warndreieck.
Das soll inkrementell entwickelt werden. Mit immer strengeren Kriterien. Es könnten auch weitere Markierungen hinzukommen, die über reine Geschwindigkeitshinweise hinausgehen könnten.
Am Ende soll das eine Art von Markierung sein, die - zumindest in der Theorie - von allen Entwicklern erreicht werden kann.
Allerdings mögen Entwickler nicht warten, bis das soweit ist. Sondern ihre Websites bereits jetzt unter dem Gesichtspunkt einer möglichst schnellen Ladezeit betrachten.
Etwa durch Nutzung von
https://developers.google.com/speed/pagespeed/insights/
einem Google-Tool.
Man könnte auch sagen: Das Thema https ist abgehakt, https ist der neue Standard. Nun folgt das nächste große Thema "Geschwindigkeit".
Auf meiner eigenen Testseite https://check-your-website.server-daten.de/ läßt sich ein Grund sehr häufig finden: WordPress-Seiten, die teils 50 oder noch sehr viel mehr JavaScript- und CSS-Dateien eingebunden haben. Es gibt auch Seiten mit über 1000 eingebundenen Komponenten. Und dann werden die Dateien teils nicht einmal mit GZip ausgeliefert und sie haben entweder keinen oder einen zu kurzen Cache-Control-Header. Oder Seiten haben massiv JavaScript und CSS-Code inline eingebunden. Das erspart zwar das Nachladen weiterer Ressourcen. Aber es führt dazu, daß es nicht möglich ist, daß Browser diese Daten cachen und bei wiederholten Aufrufen wiederverwenden.
Dabei gibt es einfache Regeln:
- Eine IPv6-Adresse nutzen. IPv6 ist etwa 5 - 10 % schneller als IPv4. Die allermeisten Websites sind noch nicht per IPv6 erreichbar. Testet man bei SSLLabs eine Seite, die sowohl per IPv4 als auch per IPv6 erreichbar ist, dann ist das IPv6-Ergebnis im Normalfall schneller verfügbar.
- GZip-Komprimierung und http/2 nutzen, JavaScript/CSS - Dateien mit Minifiern komprimieren und mit langem Cache-Control-Header senden (180 Tage oder länger).
- Nicht zu viele externe Ressourcen einbinden. Das dürfte allerdings ein grundlegendes Problem von mancher Software sein. Man braucht viele Addins, jedes Addin kommt mit eigener JS/CSS - Datei.
- Fehler bei der Datenbankanbindung oder langsame Abfragen, die bremsen.
Die eigentlichen Hardwareressourcen können zwar auch zu knapp bemessen sein. Diese sind aber nur ein Teil des Themas.