Critical Path CSS zul je vooral tegen komen, wanneer je je website door Google's PageSpeed Insights haalt. Critical path CSS houdt het volgende in: zo snel mogelijk aanleveren van kritieke CSS -verantwoordelijk voor de bovenkant van de website-, direct in het html-document. Het nut? Hiermee kan de bezoeker op een langzame internet verbinding alvast beginnen met lezen van het above-the-fold deel van de webpagina.
Critical Path CSS ten behoeve van mobiel verkeer
Critical Path CSS zul je vooral in willen zetten wanneer je website mobiel verkeer heeft. Hopelijk altijd dus. Eigenlijk kom je elke bezoeker die niet over een Wifi naar Nederlandse standaard surft, tegemoet. Denk dus ook aan vakantie-gangers die toch je media/blog website of online zakelijke diensten willen raadplegen. Weten hoe men dit ervaart, kan via Chrome's network throttling optie.
Doordat de above-the-fold CSS reeds in het HTML document ge-embed is, hoeft de browser hiervoor geen aparte request te doen. Door andere bronnen secundair te laten verwerken, wordt de bovenkant van de website alvast door de browser getekend. Terwijl de bezoeker reeds in staat is om een artikel te lezen, wordt de hoofd-stylesheet(s) ondertussen geladen. Nog niet vormgegeven zaken als onderliggende widgets of de footer, die voor de bezoeker nog niet in beeld is, worden stilzwijgend (onder de vouw) vormgegeven. Het implementeren van critical path css kan -zeker in open source systemen- een flinke pijnpunt zijn. Techniek om te adopteren, of te negeren?
Webrichtlijnen
Het direct in het HTML document embedden van CSS, zal veel (al dan niet van oudsher) frontend developers tegen de borst stuiten. Onder meer doordat het indruist tegen de webrichtlijnen (gelaagd bouwen) en zorgt voor een verminderde onderhoudbaarheid van een website. Onderhoudbaarheid valt overigens middels een CMS eenvoudig te tackelen, door de aparte critical CSS file weg te schrijven in het HTML document.
Volgende uitdaging is het feit dat de eigenlijke externe stylesheet, de embedded stylesheet niet per definitie zal overschrijven (of andersom geformuleerd: de critical path CSS kan eventuele externe style declaraties overrulen en onomkeerbaar maken voor de verschillende media queries, doordat embedded style declaraties voorrang krijgen boven externe files). De critical path CSS zal dus met zorg opgebouwd moeten worden.
Vaststellen van Critical Path CSS
Er zijn online tools om de critical path CSS automatisch te achterhalen. Keerzijde is dat deze ook direct eventuele (icon)-fonts embedden, met de nodige requests/downloads als gevolg. Dit gaat eigenlijk tegen het doel in, waardoor handmatige controle en wijziging alsnog benodigd zijn. Vaak kan het above-the-fold-deel van een website uitstekend uit de voeten zonder de iconen zelf, maar zouden de buttons waarin ze terecht komen, wel alvast getekend moeten worden. Ook is een webpagina uitstekend leesbaar zonder de voorkeurs- of huisstijl lettertype, om vervolgens na inladen vervangen te worden door het lettertype naar keuze.
Vertrouwen op caching
Een andere kanttekening is het extra gewicht dat het met zich mee kan brengen. Ook na handmatige revisie van de critical path CSS, wordt de bezoeker bij elke page-hit opgescheept met veel CSS code dat direct in het HTML document ge-embed wordt. Betekent dit dat je deze CSS dan uit de hoofd-stylesheet moet halen? Als je het goed wilt doen, wèl. Anders serveer je de bezoeker dubbele code, dat past uiteraard niet in performance optimalisatie. Kanttekening daarbij: moeilijker te onderhouden stylesheets, wat toekomstige wensen van een opdrachtgever arbeidsintensiever kan maken.
De volgende oplossingen zijn mogelijk:
- Alleen Caching
Geen gebruik maken van Critical Path CSS (waarbij een 100% PageSpeed Insights score waarschijnlijk niet behaald zal worden), maar vertrouwen op caching om de performance enigszins te waarborgen. Bronbestanden als JavaScript, afbeeldingen en ook stylesheets worden bij de juiste instellingen (vaak standaard) gecached door de browser van de gebruiker. Op vervolgpagina's hoeven diezelfde bestanden niet opnieuw gedownload te worden.
Echter onder andere voor Wordpress websites niet altijd een optie, doordat Wordpress plugins veelal met query-parameters in verwijzingen werkt, wat als gevolg kan hebben dat browsers deze bestanden niet cached. Ook worden er op vervolgpagina's binnen Wordpress sites andere plugin-bronnen gebruikt doordat plugins zelden samenwerken, waardoor een bezoeker alsnog met opvolgende requests te maken krijgt en de potentie van caching niet volledig wordt benut. - Samenwerking
Dit hebben we bereikt door een externe stylesheet, welke CSS declaraties voor het above-the-fold gedeelte bevat (= Critical Path CSS), door het CMS te laten embedden. Vervolgens wordt JavaScript asynchroon ingeladen en worden stylesheets voorzien van een media-attribuut value, waarmee deze pas secundair ingeladen wordt. De browser krijgt de tijd om de Critical Path CSS en afbeeldingen direct in de browser te tekenen.
De externe (hoofd)stylesheet wordt tegelijkertijd geladen en gecached (op iPhones tot 25kb per bestand). Op dat moment hebben we nog te maken met dubbele CSS declaraties. Echter, dit truukje wordt enkel bij een eerste page-hit toegepast. Vervolgens is de hoofd-stylesheet gecached en kunnen we het extra HTML ballast dat het Critical Path CSS met zich mee brengt, achterwege laten. Dit werkt, zo bewijst deze site, goed en zo maken we gebruik van de voordelen van beide facetten (embedded Critical path CSS en het cachen van CSS-bronnen).
AMP (project) en Critical Path CSS
Het AMP project is volgens Google een noodzakelijke gedachtegoed als antwoord op onder meer eenvoudig ogende maar zware en voor onder meer smartphones belastende websites. Mijn visie is dan ook dat websites in de basis geoptimaliseerd zouden moeten zijn, wat het AMP project overbodig zou maken.
Conclusie
Wanneer kan Critical Path CSS dan nog daadwerkelijk van nut zijn? Aan het eind van de rit lijkt het micro-optimalisatie. Wanneer je ook de genoemde cache-beperkingen van iPhones in acht hebt genomen, mag je de conclusie trekken dat dit voornamelijk een uitkomst is voor:
- Zogenaamde one-pagers of SPA's; websites of applicaties die slechts één pagina beslaan en waar een bezoeker niet verder zal navigeren, waardoor nieuwe html-requests beperkt zijn. Caching heeft dan minder toegevoegde waarde;
- Juist bij zwaardere websites of een website met internationaal publiek, kan het van toegevoegde waarde zijn om mobiele gebruikers snel te voorzien van leesbare content;
- Heb je een website met landingspagina's, waarbij vooral vanuit social media gelinked wordt? Ook dan kan het praktisch zijn Critical Path CSS te adopteren. Bezoekers vanuit social media zullen snel willen navigeren, en niet willen wachten op pagina's die lang wit blijven, totdat stylesheets -verantwoordelijk voor de layout- ingeladen zijn.
Omdat het, afhankelijk van het gebruikt CMS, arbeidsintensief kan zijn het door te voeren, zal ook de tijd en eventueel budget een rol spelen in de keuze om blokkerende scriptbronnen uit de weg te gaan. Een score van 100% in Google's PageSpeed Insights tests, als ook zoekmachine optimalisatie in het algemeen, blijft uiteindelijk een combinatie van factoren, en zolang tevredenheid bij bezoekers een factor is voor onder meer Google, behoort Critical Path CSS in onbekende mate tot die SEO factoren.
