"Hoe krijg je een 100/100-score in PageSpeed Insights?" luidt het artikel zoals door SAM Online Marketing is gepubliceerd op Frankwatching. Van de genoemde punten om tot de 100% score te komen, tel ik slechts één punt dat niet ontkracht kan worden.
Zoals (digital) marketing een vak apart is, is web performance optimization (WPO) dit ook. Desondanks is de grens ook voor online bureau's nog wel eens vaag, mocht ik eens bij OrangeValley als ook meer recent in Emerce zijn top 14 digital agencies concluderen. Gisteren kwam daar SAM Online Marketing bij, toen een Frankwatching artikel van hun hand onder mijn aandacht kwam.
Omdat vrijwel alle punten incorrect dan wel onvolledig zijn, voorzie ik het artikel via deze weg van enige tegengeluid als ook nuance. Uiteraard met het risico dat:
- ik bij hen niet op gesprek hoef te komen voor een openstaande functie;
- ik juist door SAM Online Marketing word uitgenodigd om hun eigen website met een performance score van 43% eens een flinke performance-boost te geven;
- Men performance optimalisatie in de toekomst met meer nuance toelicht.
De lijst van SAM Online Marketing is in het Frankwatching artikel als volgt, met steeds een quote uit elk paragraaf dat ik van tegengeluid of nuance voorzie.
1. Zorg voor een solide basis: hosting
Het is nog steeds belangrijk om een solide basis neer te zetten.
Hosting kan praktische toevoegingen hebben (ondersteuning voor automatische webp-afbeeldingen of HTTP/2 ondersteuning). Alhoewel de pk-vergelijking in het artikel op gaat, zal het verschil alleen merkbaar zijn als de te trekken kar (ik zit nog even in paardekracht-metafoor) overdreven zwaar is: een Wordpress of een Joomla dus.
Tot 250 keer lichter dan Wordpress
Myth busting: Er wordt niet stil gestaan bij een zwaar systeem en de impact ervan. Wanneer een zwaar systeem gehanteerd wordt, ben je inderdaad gebaat bij een duurdere hosting, terwijl een OctoberCMS van Laravel 8 keer lichter is. Het CMS dat wij inzetten is zelfs 60 tot 250 keer lichter.
Om de vergelijking meer tot de verbeelding te laten spreken: kan Wordpress bij 2GB beschikbare geheugen 8 gelijktijdige bezoekers verwerken, dan kan het Lighthouse CMS 2.000 gelijktijdige pagehits aan binnen hetzelfde webhostingpakket.
Mijn visie: De hosting vlieger gaat dus enkel op bij zware systemen, waarbij dan afgevraagd kan worden of er voor een juist systeem gekozen is als pagespeed en performance van belang is. Wat veel voorkomt, is een verkeerde platform-keuze waarbij het optimalisatie-traject juist arbeidsintensiever is dan nodig.
2. Geef voorrang aan content boven de vouw
Omdat Google wil dat bezoekers direct aan de slag kunnen, is het belangrijk om voorrang te geven aan de content boven de vouw.
Helaas heb ik dit al eens in een eerder artikel over deferred CSS kunnen ontkrachten en heb ik dat middels een demo-pagina opnieuw gedaan. Deze demo-pagina laadt alle CSS asynchroon in en CSS verantwoordelijk voor "above the fold" krijgt dus geen prioriteit. Desondanks behaalt de demo-pagina een nette 100% score in PageSpeed Insights.
Myth busting: Sinds de Google update als ook PSI update, waarbij PageSpeed Insights op Lighthouse basis plaats vindt, is dit niet meer relevant. Daarvoor wel, waarbij ik medio 2017 eens een artikel schreef over "above the fold".
Mijn visie: Het is natuurlijk nog steeds een best practice om de ervaren laadtijd (perceived performance) optimaal te houden. Het CMS dat wij inzetten handelt dit bovendien automatisch af. Echter, het is geen vereiste om tot een 100% score te komen (wat het Frankwatching artikel juist nastreeft).
3. Verklein code zoveel mogelijk
Het betekent dat je ‘overbodige’ code zoveel mogelijk moet beperken/verwijderen.
Naast bovenstaand wordt in het artikel ook gehamerd op het (laten) verwijderen van witruimtes. Uiteraard een best practice, maar is voor de 100% PSI score geen vereiste. Wederom in de demo-pagina gedemonstreerd, waarbij elk losse stylesheet als ook het HTML document zelf, nog gewoon enterregels en witruimtes bevat.
Myth busting: Ook hier wordt voorbij gegaan aan de update die PageSpeed Insights heeft ondergaan. Voorheen wilde een PageSpeed Insights rapport hier inderdaad op hameren en gtmetrix.com zal dit nog steeds doen, maar vormt een verwaarloosbare factor in de Lighthouse rapportage.
Mijn visie: Alhoewel dus verwaarloosbaar, betreft ook dit een best practice wat in sommige Content Management Systemen bovendien te automatiseren valt. Buiten bovenstaande quote om, sluit ik me verder aan bij de uitleg van dit punt.
4. Implementeer browser caching
kun je dit doen via plug-ins
Op basis van de uitleg bij dit punt, valt te concluderen dat er weinig wetenschap is van hetgeen zich onder de motorkap afspeelt of de invloed dat plugins kunnen hebben.
Myth busting: Elke plugin die je in een CMS hangt, verzwaart de website. Een mogelijk gevolg is dat de Time to First Byte (TTFB) hoger komt te liggen en inderdaad komt meer prijzige hosting dan in beeld.
Mijn visie: Uiteraard browser caching toepassen, van de simpele toepassingen nog steeds één van de meest doeltreffende optimalisatie-technieken. Stel je voor dat bij elke pagehit, de gehele stylesheet of alle afbeeldingen opnieuw van de server getrokken moeten worden. Caching instellen? Doe dit via .htaccess (heeft ook enige impact, maar in beduidend mindere mate dan plugins).
5. Optimaliseer afbeeldingen
kan dit je zo 50 punten in Pagespeed Insights opleveren
Helaas niet waar. Zelfs wanneer je webpagina voor meer dan de helft uit afbeeldingen bestaat, zal de score van je website er niet dusdanig op vooruit gaan. Dit komt doordat PageSpeed Insights nog zal hameren op next-gen formaat voor afbeeldingen: bijvoorbeeld webp. Dit maakt afbeeldingen tot wel 25% kleiner ten opzichte van JPG afbeeldingen en tot 80% ten opzichte van PNG afbeeldingen.
Myth busting: De te winnen percentagepunten is hierin helaas niet onderbouwd. Hoe dan ook zal zelfs bij optimaliseren van JPG en PNG afbeeldingen, de Lighthouse aanbeveling omtrent next-gen formaten nog niet getackeld zijn. En daar krijg je dus ook nog puntenaftrek voor. Dit had minimaal in het artikel benoemd moeten worden.
Mijn visie: Probeer de creatie van webp-afbeeldingen te automatiseren, indien de server dit ondersteunt. Is dat niet mogelijk, probeer dan het comprimeren van afbeeldingen te automatiseren, indien de server dit ondersteunt. Het LightBolt CMS doet beide bijvoorbeeld standaard automatisch. Maak in het ander geval gebruik van de in het artikel genoemde tools.
6. Bestanden verkleinen
Dit is ook een puntje waar Google erg blij van wordt
Helaas is de praktijk niet zo zwart wit. Pak de demo-pagina er nog eens bij en bekijk het aantal CSS bestanden. Dit betreffen 27 kleine CSS bestanden. Overbodig veel. Desondanks behaalt de pagina een 100% pagespeed score. Overigens zou het advies voor HTTP/2 in deze paragraaf in het Frankwatching artikel ook niet misstaan.
Myth busting: Ook hier geldt dat PageSpeed Insights voor zijn update hier inderdaad op ging hameren. Sinds november 2018 niet meer. Overigens zal hier binnen Wordpress bovendien een plugin voor nodig zijn om een poging te doen de bronnen van andere plugins samen te voegen. Dit gaat niet altijd goed en gaat bovendien ten koste van de TTFB.
Mijn visie: Desondanks een best practice. Eenvoudig te realiseren wanneer je als developer gebruik maakt van toepassingen als Grunt of Gulp. Soms kunnen systemen dit ook zonder impact op TTFB voor je uit handen nemen, waarbij gewijzigde bronnen automatisch opnieuw verkleind worden (zoals LightBolt CMS).
7. Verwijder ‘render blocking’
We komen ergens! Echter is dit ook direct het enige punt waar ik géén noemenswaardige myth busting op los kan laten.
Vooral gebruik van JavaScript zal zijn invloed hebben op bijvoorbeeld de Time to Interactive, een factor dat relatief zwaar meeweegt. De kunst is JavaScript pas uit te voeren of zelfs in te laden wanneer het door een bezoeker gebruikt gaat worden. Op die manier wordt voorkomen dat de uitvoer direct bij laden van een webpagina plaats vindt en kan een gebruiker sneller beginnen met interactie met jouw website of webshop.
PageSpeed Insights Conclusie
Als de auteur überhaupt eens een PageSpeed Insights rapportage gezien heeft, zal dit voor november 2018 zijn geweest of zal deze niet goed tegen het licht zijn gehouden noch nader onderzocht zijn. Om te voorkomen dat het artikel als waarheid wordt aangenomen, moest het van enig nuance voorzien worden.
De PageSpeed Insights rapportage is helaas minder zwart wit dan het Frankwatching artikel van SAM Online Marketing doet vermoeden. Grote winsten in scores kunnen minder snel behaald worden en de grootste bottleneck is tegenwoordig de payloads en TTI. Probeer dus in praktijk:
- Eerst de eenvoudige zaken te tackelen, zoals browser caching, text compressie en verlaging van TTFB;
- Aanwezige JavaScript onder de loep nemen en verwijderen wat niet nodig is. Vaak kan hierdoor ook in DNS lookups en dus network latency bespaard worden;
- Ga vervolgens over op overige aanbevelingen, die afhankelijk van het gebruikt systeem arbeidsintensief kunnen zijn.
Second opinion of myth busting op andere beweringen benodigd? We horen het graag!
