PageSpeed Insights: Inhalte "above the fold" / Rendering

faglork · 26. März 2015 14:24

Moinsen!

Google Pagespeed schlägt zur Verbesserung ja vor, wichtige CSS-Teile inline zu laden:

https://developers.google.com/speed/doc … SSDelivery

"Ermitteln Sie im Fall einer großen CSS-Datei den CSS-Code, der zum Rendern des ohne Scrollen sichtbaren Inhalts erforderlich ist. Platzieren Sie ihn inline und lassen Sie die übrigen Stile nach dem ohne Scrollen sichtbaren Inhalt laden."

Nun ist das Beispiel auf oben genannter Seite ja für A... - das Rendering wäre da ja auch ohne das CCS möglich. Im Beispiel auf der Seite geht es um blaue Schriftfarbe. Das kanns doch wohl nicht sein ...

Nun ist mir nicht ganz klar was denn eigentlich "CSS-Code, der zum Rendern des ohne Scrollen sichtbaren Inhalts erforderlich ist" ist. Wenn die Seite ordentlich linearisiert ist, dann ist doch die Darstellung a.k.a "Rendering" prinzipiell auch komplett ohne CSS möglich?

Was will Google denn da genau? Ist mir nicht klar.

Kann mich mal jemand aufklären ;-)

Servus,
Alex

Beitrag geändert von faglork (26. März 2015 14:26)

NaN · 26. März 2015 19:17

Naja, so wie ich das verstehe, geht es darum … ich versuch's mal in Form von Code auszudrücken:

Hier klicken, um den Code zum Kopieren zu markieren

<html>
    <head>
        <style>
            #above_the_fold {…}
        </style>
    </head>
    <body>
        <header id="above_the_fold">…</header>
        <footer id="below_the_fold">…</footer>
    </body>
</html>

Der Footer wird dann im externen CSS gestylt.

rage_all · 27. März 2015 13:51

Naja, selbst - oder gerade - das externe verursacht ja laut Google Speedprobleme.
Mein bestes Ergebnis bei Google sind 94/100. Auch hier: Ich soll die bootstrap.min.css und das Page-Style CSS (welches von CMSms kommt) erst nach dem Fold laden und nur die aller-notwendigsten Sachen für above-the-fold wahlweise extern oder inline (beides wäre wohl okay). Fein soweit - aber wie wird das realisiert?

CSS muss nach W3C im <head> stehen, sonst ist es nicht valide. Für <script> gibt es async aber nicht für CSS. Jetzt bastel ich gerade an einer Lösung via js mit einem dynamischen nachladen nach dem onload-Event und einem <noscript> als Fallback-Lösung. Nicht weil es unbedingt sein müsste - aber spaßeshalber will ich die 100 wenigstens 1x im Leben geschafft haben... big_smile
(wofür ich bestimmt auch noch die 513 Byte im HTML-Code aufräumen müssen werde...)

NaN · 27. März 2015 17:52

Eventuell könnte auch dieser Beitrag nützlich sein: https://css-tricks.com/authoring-critical-fold-css/

NaN · 28. März 2015 12:38

Ein einfacher Trick, CSS asyncron zu laden, ist, ein "fake-Media-Attribut" zu verwenden. Da Stylesheets, die nicht für das aktuelle Ausgabemedium gedacht sind, automatisch asynchron geladen werden, kann man mit Hilfe von Javascript beim onload-Event einfach das media-Attribut des externen CSS ändern.
Beispiel: https://heikomamerow.de/wordpress/blog/ … ron-laden/

faglork · 01. April 2015 09:56

NaN schrieb:

Eventuell könnte auch dieser Beitrag nützlich sein: https://css-tricks.com/authoring-critical-fold-css/

Danke für den Link!

Leider lässt auch dieser Artikel die Frage unbeantwortet: Was zum Teufel ist denn "critical"?

"color:red" ist doch völlig irrelevant ... oder reicht es, einfach ein paar fake-Angabe reinzuschreiben, nur damit Google Ruhe gibt?

"critical" für was? Eine ordentlich linearisierte Seite kann auch ganz ohne CSS gerendert werden - also was bitte schön ist "critical"?

Ich habe mal das auf dieser seite erwähnte Online-Tool benutzt. Als KRITISCH wurden u.a. gewertet:
html {background:#fff;}
body {-webkit-font-smoothing:antialiased;}

Da komme ich mir jetzt schon etwas vergaggeiert vor.

Und wie wirkt sich das denn aus? Ich setze also ein paar "kritische" Angaben in den HEAD, damit die Seite sofort gerendert werden kann. Die wird doch dann auch angezeigt, oder nicht? Eine Sekunde später kommt der Rest vom Stylesheet und alles wird neu gerendert? Das heisst es macht "puff" und die Seite sieht auf einmal anders aus?

Konkret "below the fold" ist bei mir meistens nur der Footer, alles andere beginnt jedenfalls schon "above" d.h. es ist dort mindestens teilweise sichtbar. Wenn das jetzt *komplett* gerendert werden soll, dann landet der überwiegende Teil meines CSS im HEAD. Das kanns doch auch nicht sein? Wenn es aber *nicht komplett* gerendert werden soll, wo liegt denn da die Grenze?

Also irgendwie tu ich mir da sehr schwer mit dem Verständnis. Hat jemand mal ein "echtes" Beispiel für sowas? Eine Live-Website, die sowas einsetzt?

Servus,
Alex

Beitrag geändert von faglork (01. April 2015 09:57)

NaN · 01. April 2015 12:06

Leider lässt auch dieser Artikel die Frage unbeantwortet: Was zum Teufel ist denn "critical"?

Wenn ich das richtig verstanden habe, dann wird das in den beiden verlinkten Artikeln genau gesagt:

Determining what is critical
Determining which portions of our CSS are critical required inspecting my web pages at "mobile" and "desktop" sizes, then taking a snapshot of the CSS rules applied to the elements visible in the viewport.

Kritisches und unkritisches CSS
Was ist kritisches CSS? Kritisches CSS sind die Styles, die man für den sichtbaren Bereich einer Website benötigt = Above the fold. Das ist der sichtbare Bereich im Browser, wenn eine Seite geladen wurde und man noch nicht gescrollt hat.

Das critical bezieht sich also darauf, ob das Element sichtbar ist und via CSS formatiert wird. Wie genau diese Formatierung aussieht, ist dabei wurscht. Alles was Du brauchst, um das Element so darzustellen wie es dargestellt werden soll, sollte inline sein. Und wenn es nur ein "color:red" ist. Für die Geschwindigkeit beim Rendern der Seite ist es wichtig, dass ein Element nur ein einziges Mal gerendert wird. Wenn Du z.B. Deiner Meinung nach "unwichtige" Styles nachlädst, diese Styles aber wiederum auf Elemente "Above the fold" angewendet werden sollen, löst das beim Browser ein sogenanntes "repaint-Ereignis" aus. Und das ist wiederum eine Performance-Bremse.
Hier noch ein interessanter Artikel: http://www.stubbornella.org/content/200 … ript-slow/

According to Opera, repaint is expensive because the browser must verify the visibility of all other nodes in the DOM tree.

Es geht also rein um die Performance beim Anzeigen. Nicht um Semantik o.ä.

faglork · 02. April 2015 12:08

NaN schrieb:

Das critical bezieht sich also darauf, ob das Element sichtbar ist und via CSS formatiert wird. Wie genau diese Formatierung aussieht, ist dabei wurscht. Alles was Du brauchst, um das Element so darzustellen wie es dargestellt werden soll, sollte inline sein. Und wenn es nur ein "color:red" ist.

Bei einem "Standard-Design" (Kopfzeile, 3 Spalten, Fusszeile) ist das aber ALLES ausser der Fusszeile. Inklusive sämtlicher @media-Geschichten. Das ist nicht grad wenig - das verdoppelt locker die Dateigröße. Und gecached kann es ja nicht werden.

IMO ergibt das nur einen Sinn wenn man eines dieser gehypten "1-Page-Designs" verwendet. Da ist fast alles "under the fold".

NaN schrieb:

Für die Geschwindigkeit beim Rendern der Seite ist es wichtig, dass ein Element nur ein einziges Mal gerendert wird. Wenn Du z.B. Deiner Meinung nach "unwichtige" Styles nachlädst, diese Styles aber wiederum auf Elemente "Above the fold" angewendet werden sollen, löst das beim Browser ein sogenanntes "repaint-Ereignis" aus. Und das ist wiederum eine Performance-Bremse.
Hier noch ein interessanter Artikel: http://www.stubbornella.org/content/200 … ript-slow/
According to Opera, repaint is expensive because the browser must verify the visibility of all other nodes in the DOM tree.
Es geht also rein um die Performance beim Anzeigen. Nicht um Semantik o.ä.

Das verstehe ich nun wirklich nicht mehr. D.h. das Prinzip mit dem Nachladen ist mir schon klar. Aber Google redet ja von "blocking css". Das heisst (IMO), die Seite wird *gar nicht gerendert* solange das CSS nicht geladen ist. Aber einen Teil davon inline reinschreiben und dann wird nicht mehr geblockt? Ab wieviel "Teil" wird nicht mehr geblockt? Woher weiss der Browser dass der inline-Teil vollständig ist? Und woher weiss Google das? Google kennt doch die aktuelle Bildschirmgröße gar nicht. Reicht es "color:red" in den HEAD zu schreiben und alles ist gut?

Ich glaub ich steh da völlig auf dem Schlauch.

Und nochwas. Das "above the fold" sieht ja bei mobilen Geräten ganz anders aus. DA kann ich mir das wieder vorstellen. ABER: das hieße ja, *abhängig von der Bildschirmdimension* Teile des CSS inline darzustellen oder nicht. Und das heisst, dass quasi dynamisch die CSS-Inhalte zwischen inline und externem CSS hin-und herwandern können müssen. Wie soll das denn gehen?

Ich habe da ein echtes Vertändnisproblem.

Servus,
Alex

NaN · 02. April 2015 13:51

Aber einen Teil davon inline reinschreiben und dann wird nicht mehr geblockt?

Jein. Nur, wenn das restliche CSS asynchron geladen wird (siehe den Link mit dem "fake-media-attribut").

Ab wieviel "Teil" wird nicht mehr geblockt?

Es kommt dabei nicht auf die Menge an. Das Blockieren bezieht sich auf den Ladevorgang des übrigen CSS.

Woher weiss der Browser dass der inline-Teil vollständig ist? Und woher weiss Google das?

Das interessiert die beiden nicht.

Du sollst den Teil inline reinschreiben, der für die Darstellung der above-the-fold-Elemente nötig ist. Auch wenn dieser Teil mehr als nur die above-the-fold-Elemente betrifft. Nimm ihn aus dem externen CSS raus und pack ihn inline. Ob das inline-CSS damit vollständig ist, oder die inline-Styles zusätzlich auch auf den Footer angewendet werden, oder zusätzliche externe CSS asynchron geladen und später auf den Rest - den derzeit ohnehin nicht sichtbaren Teil der Seite - angewendet werden, das ist Google egal. Hauptsache das, was above-the-fold ist, wird so schnell wie möglich dargestellt. Das was gerade nicht im Viewport ist, interessiert dabei nicht.

Google kennt doch die aktuelle Bildschirmgröße gar nicht.

Google geht dabei vom aktuellen Stand der Technik bzw. deren Verbreitung aus. Also die derzeit am häufigsten verwendeten Bildschirmgrößen/-auflösungen etc.
Und dafür sollst Du Deine Seite optimieren, nicht individuell für jeden einzelnen Webseitenbesucher.

Ich glaub ich steh da völlig auf dem Schlauch.

Nee, ich glaube, Du verstehst das schon richtig. Man kann es nur nicht jedem Recht machen bzw. ist es auch nicht ganz so einfach.

ABER: das hieße ja, *abhängig von der Bildschirmdimension* Teile des CSS inline darzustellen oder nicht. Und das heisst, dass quasi dynamisch die CSS-Inhalte zwischen inline und externem CSS hin-und herwandern können müssen. Wie soll das denn gehen?

Ich würde mich da nicht auf Bildschirmdimensionen sondern auf den User-Agent verlassen. Da könnte man schon serverseitig zwischen Smart-Phone, Tablet, Desktop und Smart-TV filtern. D.h. Smartphones erhalten nur inline-Styles, die Smartphones betreffen. Und so viele gängige Bildschirmgrößen gibt es je Gerät nun auch wieder nicht zu beachten, dass man sein Inline-CSS mit den für z.B. Smartphones zu berücksichtigenden @media Queries überfrachten würde. Bei Smartphones interessiert mich eigentlich nur, ob Landscape oder Portrait. Vielseitiger wird's dann erst bei Tablets und Desktops. Das endet dann allerdings in einem Sammelsurium von mindestens 9 zu verwaltenden Stylesheets. (je Ausgabegerät ein inline und ein externes CSS plus Print)

rage_all · 07. April 2015 13:49

Anstatt mit loadCSS mit einem einfachen javascript.append:
Muss ich in diesem Fall auf {cms_stylesheet} verzichten?

Mein Ansatz:
Ich habe kritisches CSS in einer externen File, die im <head> aufgerufen wird.
Dazu habe ich das Framework-CSS in einem <noscript> und lade es später mittels jQuery nach ($("head").append($("<link rel='stylesheet' href='...).

Außerdem habe ich aber ja noch mein eigenes, vollständiges CSS das von CMSms kommt zu handeln, derzeit via {cms_stylesheet}. Wie kann ich das nachträglich laden? Kann ich aus einem UDT diese Funktion auch aufrufen oder wie wäre das noch elegant zu lösen?

Das mit dem loadCSS habe ich nicht gemacht ... mir erschließt sich das Ganze noch nicht. Auf der Projektseite wird schon von diversen Browsern gesprochen die das wiederum nicht unterstützen und hick-hack-hier-hick-hack-da ... mir scheint stattdessen <noscript> mit einem einfachen .append mittels jQuery sinniger und kompatibler.

Aber, nu krieg ich das mit der CMS_STYLESHEET-Funktion nicht um die Kurve... big_smile

NaN · 07. April 2015 15:11

Aber, nu krieg ich das mit der CMS_STYLESHEET-Funktion nicht um die Kurve...

Sei kreativ! wink
Pack doch das {cms_stylesheet} in ein <noscript>-Tag mit einer ID und dann hole es via Javascript von dort:

Hier klicken, um den Code zum Kopieren zu markieren

<noscript id="css">
    {cms_stylesheet}
</noscript>
<script>
    $("head").append($("#css").html());
</script>

Weiß allerdings auch nicht, wie Browserkompatibel das ist.

rage_all · 07. April 2015 15:53

NaN schrieb:

Sei kreativ!

...sagt er da so einfach... wink

Funktioniert hat das soweit schon ... aber ich habe plötzlich Fehler in der Konsole bekommen und mir hat es an einigen Stellen einiges im Layout und der Funktion verhaut.
Momentan vermute ich Probleme in der Reihenfolge von dem ganzen CSS/JS Brei.

Huh. Google gibt mir jetzt 85 und 95 für Mobile und PC.
Umgestellt auf das Konzept mit Bootstrap und meinem CSS via jQuery hatte ich 73 und 100. hmm
Damit muss ich mir die Frage stellen, ob ich mir das echt noch geben soll oder ob das so auch reicht.

Derzeit wird nur die CSS von Bootstrap mokiert und meine CSS, sonst aber nichts. Wenn ich die beiden später nachlade, werden mir dafür die drei .js Dateien angemault plus Priorisierung , jedenfalls auf Mobile.
Ich glaube das ist was für einen verregneten Sonntagnachmittag... tongue

NaN · 07. April 2015 16:46

Wenn ich die beiden später nachlade, werden mir dafür die drei .js Dateien angemault plus Priorisierung , jedenfalls auf Mobile.

Welche drei js-Dateien?

rage_all · 07. April 2015 17:26

Jetzt krieg ich sicher gleich Ärger... wink

Insgesamt habe ich drin (in dieser Reihenfolge):

jquery-1.11.0.min.js
jquery-migrate-1.2.1.min.js
bootstrap.min.js
etwas Inline-JS (unter anderem für das deferring)

...und Piwik - aber das zählt glaube ich nicht...

rage_all · 17. Juli 2015 22:20

Heute hab ich voller Schrecken festgestellt, dass Chrome offenbar mit

Hier klicken, um den Code zum Kopieren zu markieren

[== JavaScript ==]
$("head").append($("#css").html());

nicht ganz klar kommt. Bei mir hat sich das insofern ausgewirkt, dass die Navigation nicht ging. In Chrome war im collapsed-mode das Menü komplett unbrauchbar (klappte sich aus und innerhalb einer viertel Sekunde wieder ein); im Desktop-mode gingen alle Links, bis auf die Dropdown (die waren dafür komplett tot).
Nachdem ich normalerweise mit FireBug nach Fehlern suche und mich erstmal in die Chrome Erweiterung einfuchsen musste, hat die Fehlersuche einen halben Tag gebraucht... yikes

Wohl werden die Links zwar im <head> zugefügt, aber innerhalb von Anführungszeichen. Was das nun genau macht, weiß ich nicht. Ich hab nur mehrfach im Netz den Hinweis gefunden man möge dabei sehr acht geben, wenn man Chrome-, bzw. Webkit-Kompatibilität wünscht (oder sich ebendiese selbst dazuschreiben).
Siehe z.B. https://www.google.de/search?q=chrome+head+append

Nun (meine) finale Lösung, die mir immerhin nun sowohl für Desktop als auch Mobile 99/100 Punkten im Speedtest bringt:
Unmittelbar vor </body> folgendes JS:

Hier klicken, um den Code zum Kopieren zu markieren

[== JavaScript ==]
$("head").append($("<link rel='stylesheet' href='template/studio/css/bootstrap.min.css' type='text/css' media='all' />"));
$("head").append($("<link rel='stylesheet' href='{cms_stylesheet nolinks=1}' type='text/css' media='all' />"));

Dazu natürlich das sagenumwobene "kritische" CSS (welches ich der Website von Jonas Sebastian Ohlsson verdanke) - tata... big_smile

Hier der Link zum Speedtest (ich hoffe das ist kein Spam big_smile ): https://developers.google.com/speed/pag … tab=mobile

Ach ja, die letzten 641 Byte die ich noch optimieren könnte (in der komprimierten und gestrippten CSS) können mir gestohlen bleiben... *lach*
Das einzige was diese Tage noch kommen wird, sind weitere Subdomains für CSS, JS und Bilder. Dann möchte ich schauen ob ich die Zeiten bis zum Rendern so noch auf unter 1 Sekunde bekomme.

Edit: Vielen Dank an NaN, für die Idee die Daten mittel JS nachzuziehen! Auf diese Lösung wäre ich nicht so schnell gekommen und sie scheint mir äußerst effektiv zu sein.

Beitrag geändert von rage_all (17. Juli 2015 08:33)

Andynium · 18. Juli 2015 19:27

faglork schrieb:

Google Pagespeed schlägt zur Verbesserung ja vor, wichtige CSS-Teile inline zu laden:
https://developers.google.com/speed/doc … SSDelivery

Hat jemand hierzu schon mal ausgetestet, das CSS komplett inline zu setzen?

Spart zumindest einen Request ...

Forum für CMS/made simple

#1 26. März 2015 14:24

PageSpeed Insights: Inhalte "above the fold" / Rendering

#2 26. März 2015 19:17

Re: PageSpeed Insights: Inhalte "above the fold" / Rendering

#3 27. März 2015 13:51

Re: PageSpeed Insights: Inhalte "above the fold" / Rendering

#4 27. März 2015 17:52

Re: PageSpeed Insights: Inhalte "above the fold" / Rendering

#5 28. März 2015 12:38

Re: PageSpeed Insights: Inhalte "above the fold" / Rendering

#6 01. April 2015 09:56

Re: PageSpeed Insights: Inhalte "above the fold" / Rendering

#7 01. April 2015 12:06

Re: PageSpeed Insights: Inhalte "above the fold" / Rendering

#8 02. April 2015 12:08

Re: PageSpeed Insights: Inhalte "above the fold" / Rendering

#9 02. April 2015 13:51

Re: PageSpeed Insights: Inhalte "above the fold" / Rendering

#10 07. April 2015 13:49

Re: PageSpeed Insights: Inhalte "above the fold" / Rendering

#11 07. April 2015 15:11

Re: PageSpeed Insights: Inhalte "above the fold" / Rendering

#12 07. April 2015 15:53

Re: PageSpeed Insights: Inhalte "above the fold" / Rendering

#13 07. April 2015 16:46

Re: PageSpeed Insights: Inhalte "above the fold" / Rendering

#14 07. April 2015 17:26

Re: PageSpeed Insights: Inhalte "above the fold" / Rendering

#15 17. Juli 2015 22:20

Re: PageSpeed Insights: Inhalte "above the fold" / Rendering

#16 18. Juli 2015 19:27

Re: PageSpeed Insights: Inhalte "above the fold" / Rendering

Fußzeile des Forums