Ladegeschwindigkeit - leidiges Thema

Ich muss leider nochmals auf das Thema Ladegeschwindigkeit zurückkommen. Kann man da wirklich nichts machen? Hier die Meldung von Page Speed Insights: Anfragen blockieren das erste Rendering der Seite, was den LCP verzögern kann. Durch das Verschieben oder Einfügen können diese Netzwerkanfragen aus dem kritischen Pfad entfernt werden.LCPFCPNicht bewertet

Laut KI sieht es so aus: Das ist der absolute Klassiker bei PageSpeed Insights! Bei der Datei, die du hier gepostet hast, handelt es sich um die bekannte JavaScript-Bibliothek jQuery (Version 3.6.0).

Dass PageSpeed sich darüber beschwert, hat meistens zwei Gründe:

1. Die Datei ist unminifiziert: Der Code, den du gepostet hast, enthält alle Kommentare und Formatierungen. Das ist die Entwickler-Version, die viel zu groß für eine Live-Website ist.
2. Sie blockiert das Rendern (Render-Blocking): Standardmäßig lädt der Browser solche Skripte im Kopfbereich (<head>) der Website herunter und führt sie aus, bevor er überhaupt anfängt, das Design der Seite für den Nutzer aufzubauen.

Wenn ich es richtig interpretiere, ist das ein Zeta-Problem - oder?

Danke für den Hinweis. Beim Computer gibt es grundsätzlich keine Probleme, wenn man auf die Dateigröße (Komprimierung) achtet und die Schriftart "Open Sans" vermeidet. Eine CDN-Aktivierung hilft auch. Schwierigkeiten gibt es oft mit der mobilen Version. Beispiel: Ich habe das wohl sparsamste und einfachste Layout verwendet (Swiss Responsive Clean) und die Kopfgrafik in das Format webp. umgewandelt (70 KB). Das Resultat zeigt die beigefügte Grafik: Leistung = 69. Das wäre normalerweise kein Problem, aber für Google Discover ist das zu viel, zumal dort eine Mindestbreite der Infografiken von 1.200 Pixel verlangt wird. Laut KI hängt das mit zwei Problemen zusammen, die ich als absoluter Laie weder verstehen noch beheben kann. Problem 1: Das Problem: Bei allen statischen Dateien (bundle.js, bundle.css, Schriften und sogar dem Logo) steht bei Cache-TTL der Wert „None“. Die Ursache: Dein Webserver ist aktuell so konfiguriert, dass er den Browsern der Besucher verbietet, diese Dateien im lokalen Zwischenspeicher (Cache) zu sichern. Das bedeutet: Wenn ein Leser von deiner Startseite auf einen Artikel klickt, muss sein Browser die riesige bundle.js (513 KiB) und die bundle.css (131 KiB) jedes Mal komplett neu vom Server herunterladen, obwohl sich diese Dateien nie ändern. Das vervielfacht die Last und die Ladezeit bei jedem Klick. Dieses Problem lässt sich wohl über die htaccess lösten.

Problem 2: Das Problem: bundle.js (513 KiB) und bundle.css (130,5 KiB) blockieren das Rendering. Das JavaScript allein braucht über 3,7 Sekunden (3.790 ms), um geladen und verarbeitet zu werden. In dieser Zeit sieht der Nutzer: Nichts.

Lösung für Problem 2: Im Quellcode / CMS-Template

Da du vorhin Zeta Producer erwähnt hast (oder falls ein anderes CMS im Hintergrund von managerimpulse.org läuft): Das System generiert das HTML-Gerüst. Du musst in den Einstellungen deines Templates oder im Quelltext der Master-Datei das Attribut defer in das Script-Tag einbauen.

• Aktuell steht dort vermutlich: <script src="/assets/bundle.js?v=639..."></script>
• Es muss dort stehen: <script src="/assets/bundle.js?v=639..." defer></script>

Deswegen wende ich mich an Zeta.

ok, danke.