Newbie braucht Hilfe bei Google Pagespeed Insight

Linda255

Hallo ihr Lieben,

ich brauch mal dringend Hilfe von Leuten die mehr Erfahrung haben als ich - den ich bin Newbie. Ich habe meine Spieleseite bei Google Pagespeed Insight analysieren lassen. Hier der Link von der Analyse: https://developers.google.com/speed/pag ... ab=desktop

Wenn ihr dem Link folgt wird angezeigt: JavaScript- und CSS-Ressourcen, die das Rendering blockieren, in Inhalten "above the fold" (ohne Scrollen sichtbar) beseitigen. Ihre Seite enthält 1 blockierende Skript-Ressourcen und 3 blockierende CSS-Ressourcen. Dies verursacht eine Verzögerung beim Rendern Ihrer Seite.

Ich habe den Pagespeed jetzt schon auf 83 Punkte hochgeschraubt mit meinen Kenntnissen, ich würde sehr gerne auch noch dieses Problem beheben, aber ich hab keinen Plan davon, was ich hier machen muss und wieso hier das Rendering und CSS blockieren. Ich hoffe mir kann jemand helfen, bzw. sagen was ich zu tun habe.

Viele Grüße Linda

[btk]tobi

Hallo,

das Javascript kannst du asynchron einbinden

Code: Alles auswählen

<script src="script.js" async></script>

Bei den CSS Dateien kannst du nicht viel machen, außer die im Footer einbinden was dann nicht valide ist. Google empfiehlt hier das man alles sichtbare CSS inline schreibt und dann irgendwo mitten im HTML Dokument das CSS einbindet oder eben per JS nachlädt. Ich persönlich halte das für Schwachsinn, zumindest wenn man HTTP/2 verwendet blockiert das CSS auch nicht und auch ohne nur bei ersten Seitenaufruf, danach liegt es eh im Browsercache.

Optimiere lieber deine Bilder und gib ihnen eine Cachezeit.

Gruß Tobi

IMHO

@[btk]tobi: das mit dem Schwachsinn von "Googles Empfehlung" sehe ich genauso.

Es mag bei extrem großen oder vielen js/css Dateien helfen. Aber bei 2-3 Dateien von mit jeweils 20-30KB oder so, hat das zwar messbare Auswirkungen (im 2stelligen Millisekunden Bereich) hilft aber der Nutzererfahrung Null. Und erzeugt viel Aufwand.

@Linda255:
Ich würde den Fehler: "JavaScript- und CSS-Ressourcen, die das Rendering blockieren, in Inhalten "above the fold" (ohne Scrollen sichtbar) beseitigen" ignorieren.
Denn auch mit diesem "Fehler" kommt man durchaus auf über 90 (und damit grün).

Und mich um die anderen Meckereien kümmern.

P.s.

Hier eine Seite die in allen drei Bereichen auf 100/100 Punkten kommt:
www*twitterpolitik*net

Christian-E

Hallo Linda,

der Punkt ist meist nur sehr aufwendig zu beheben.

Du müsstest Dir genau anschauen, welche CSS-Formatierungen above-the-fold benötigt werden, diese aus den CSS-Dateien herausholen und dann inline ausgeben.
Ähnlich wäre es mit dem Javascript, das ist aber meist noch viel kniffliger umzusetzen, besonders wenn so Sachen wie jquery verwendet werden.

Aus meiner Sicht macht dieser Aufwand nur für Seiten Sinn, die richtig Traffic ziehen. Ansonsten sind die Vorteile zu gering.

Schöne Grüße
Christian

Linda255

[btk]tobi hat geschrieben:
Optimiere lieber deine Bilder und gib ihnen eine Cachezeit.

Gruß Tobi

Hallo danke für eure Antworten. Leider haben mir die erklärungen nicht so doll weitergeholfen, da eure Antworten ein größe Wissen als mein momentan vorhandenes voraussetzen. Was ich verstanden habe ist, ignorieren und zu aufwendig.

Wie kann ich denn meinen Bildern Cachezeiten geben? Kann mir das jemand erklären?

Viele Grüße Linda

[btk]tobi

Wenn du den Apache Webserver benutzt: https://tas2580.net/blog/webseite-htacc ... ieren.html

Gruß Tobi

Can

Cachezeiten nach möglichkeit nicht per htaccess sondern im vhost definieren.

Das inline css macht schon Sinn. Ist mit NodeJS z.B. auch sehr schnell umgesetzt. Muss aber nicht, ist wirklich perfektion dann.

top

IMHO hat geschrieben:...

Hier eine Seite die in allen drei Bereichen auf 100/100 Punkten kommt:
www*twitterpolitik*net

Ich hatte gehofft hier mal ein funktionierendes Beispiel zu finden, bei dem die CSS-Dateien dynamisch nachgeladen werden.
Aber so ist das ja schon fast geschummelt.

Kein JavaScript, relativ spartanisches Layout ohne Navigation und kleine Bilder. Da bleibt nicht mehr viel übrig wobei man Fehler machen kann.

Packt man die CSS (wie es meistens auch sinnvoller ist) in eine separate Datei, gibt es auch keine 100 Punkte mehr. (Auf der Seite gut zu sehen wenn man mal die Impressums-Seite testet.

)

Was allerdings auch etwas bringt, ist sämtliche CSS-Dateien und JS-Dateien jeweils in eine Datei zu bündeln. Dann meckert Pagespeed nur noch mit einem gelben Hinweis und nicht mehr mit einer roten Warnung.

Hier mal ein Beispiel: www*dr-petra-boehmer*de
Dort hatte ich auch mal Testweise die komplette CSS in den Head gepackt. (Einfach mal die "test.html" öffnen) Dann komme ich zwar auf 100%, das würde dann aber für jeden weiteren Aufruf der Unterseiten wieder zusätzliche 30KB bedeuten. Da finde ich es eleganter wenn die CSS-Daten beim Aufruf der Unterseiten schon im Browsercache liegen.

Ach ja, den kompletten CSS-Teil in den Head zu packen funktioniert auch nur bis zu einer bestimmten Größe. Irgendwann meckert Pagespeed, dass der HTML-Quellcode zu groß ist.

elmex

top hat geschrieben:Ich hatte gehofft hier mal ein funktionierendes Beispiel zu finden, bei dem die CSS-Dateien dynamisch nachgeladen werden.

Bitte schön:

https://developers.google.com/speed/pag ... tab=mobile

Can

elmex hat geschrieben:
top hat geschrieben:Ich hatte gehofft hier mal ein funktionierendes Beispiel zu finden, bei dem die CSS-Dateien dynamisch nachgeladen werden.
Bitte schön:

https://developers.google.com/speed/pag ... tab=mobile

Das ist ein sehr schlechtes Beispiel da das CSS hier async lädt und damit die komplette Seite springt. Richtig implementiert liegt das benötigte CSS wie bereits angesprochen inline.

elmex

Can hat geschrieben:Das ist ein sehr schlechtes Beispiel da das CSS hier async lädt und damit die komplette Seite springt. Richtig implementiert liegt das benötigte CSS wie bereits angesprochen inline.

Und WAS war seine Frage?

Can

elmex hat geschrieben:
Can hat geschrieben:Das ist ein sehr schlechtes Beispiel da das CSS hier async lädt und damit die komplette Seite springt. Richtig implementiert liegt das benötigte CSS wie bereits angesprochen inline.
Und WAS war seine Frage?

...

"funktionierendes Beispiel"

ich interpretiere das als vollständig, korrektes Beispiel.

top

elmex hat geschrieben:
Can hat geschrieben:Das ist ein sehr schlechtes Beispiel da das CSS hier async lädt und damit die komplette Seite springt. Richtig implementiert liegt das benötigte CSS wie bereits angesprochen inline.
Und WAS war seine Frage?

Danke, genau so ein Lösungsansatz hat mich interessiert.
Die Seite macht auch mich auch noch den Eindruck, als befände sie sich noch im Aufbau. Daher ignoriere ich das "Springen" beim Seitenwechsel einfach mal weg. Um den priorisierten Teil der CSS würde ich mich auch erst später kümmern, um es im Seiten-Head abzulegen.

Vor allem gefällt mir, dass man dafür nicht wieder ein zusätzliches JS einbinden muss. Im Head sind es nur ein paar Kleinigkeiten mehr und am Seitenende gibt es nur eine kurze Zeile Javascript.

Wobei ich es vielleicht niemals einsetzten werde. Der Aufwand den man da betreiben muss, erscheint mir momentan noch zu hoch im Verhältnis zum Nutzen den man davon hat. Sofern man denn von Nutzen sprechen möchte. Auch wenn die Seite dadurch einen winzigen Moment früher dargestellt wird - letztlich erhöht sich dadurch die Gesamtmenge der Daten und den deutlichen Mehraufwand erhöht sich die Fehleranfälligkeit.

Aber vielleicht habe ich ja mal einen Kunden, der für seine Webseite unbedingt dort "100%" stehen haben möchte - egal ob sinnvoll oder nicht.

Can

top, was hast du dem auf dem Server zur Verfügung? Mit PHP war es zumindest als ich das letzte mal geschaut habe ein Krampf, da lohnt das nicht. Zum CSS Lazyload und Pagespeed Test gab es mal von Elitepartner eine Case Study, das habe ich so schon oft implementiert bin sehr zufrieden. Spielerei auf uu6 ist ein bisschen sketchy, allein der Timeout.

Gerade wenn wie gesagt JavaScript vorhanden ist lassen sich die Seiten sehr einfach mit PhantomJS verarbeiten. Hängt natürlich auch immer vom Maß der Dynamik der Seite ab. Ich habe aber in jedem Projekt eine Verbesserung der Conversion Rate erzielt. Meine Meinung dazu: eine schnellere Seite lädt mehr zum Klicken, Stöbern und Konfigurieren ein, ich bezeichne solche Seiten dann immer als besonders "klickerig".

Aktuell gehe ich deswegen sogar soweit, dass ich Angular 2 Projekte (JavaScript Framework) vollständig auf dem Server "pre"-rendere und dem Client statisch ausgebe, das Framework bringt die Dynamik // Logik dann anschließend wieder herein. Somit hat man Ladezeiten von unter 200ms.

IMHO

@top: Du hast in allen Punkten recht (auch wenn ich vermute, dass eine Navigation und (optimierte Bilder) an der Wertung nichts ändern würden).

Und das Google Pagespeed die Einstufung von „Rot“ nach „Gelb“ ändert (wenn sonst fast alles ok ist) hatte ich auch schon malbeobachtet, war mir aber nicht mehr ganz sicher. Und ich bin mir auch nicht ganz sicher, ob eine *einzige* JS/CSS Datei dafür zwingende Voraussetzung ist.