De PageSpeed Insights is door Google aangevuld met real-user data, om inzage te geven in de gemiddelde ervaring omtrent verschillende metrics van je website. Achter de schermen is er echter meer veranderd, waardoor je webpagina's ineens een hoger, of juist lager uitgevallen score kan hebben.
PageSpeed Insights veranderingen aan je voorbij gegaan? Tegenwoordig tref je er echte bezoeker-data aan, waar het huidig artikel een vervolg op is.
De 100% PageSpeed score op onze website, als ook websites in aanbouw, staan nog overeind. Echter, bij het testen van andere websites, of te vervangen websites, heb ik andere verschuivingen binnen PageSpeed's Optimization score geconstateerd.
PageSpeed Insights's Optimization score
De Optimization score binnen de PageSpeed Insights report, is door de aanvulling van de real-world user data voor de Speed score ingeperkt. Tijdens tests ben ik tot de conclusie gekomen dat enkele suggesties en handvaten van ondergeschikt belang zijn geworden, en één aspect juist belangrijker is geworden.
Leverage browser caching
Voorheen werd al snel 15 procent-punten in mindering gebracht op je algehele PageSpeed score wanneer je bronbestanden geen caching-duur meegaf. Dit betekende dat browsers bepaalde bronbestanden met een hogere frequentie zouden downloaden dan noodzakelijk, en caching dus geen voordeel opleverde. Dit werd door Google's PSI report bekend gemaakt onder noemer "Leverage browser caching".
Tegenwoordig lijkt dit je hooguit 1 procent-punt te kosten, ongeacht of er tientallen bestanden zonder optimale cachingduur geserveerd worden, of dat alleen die enkele google-analytics file voor een te lange cachingduur zorgt.
Minify JS en CSS
PageSpeed Insights lijkt zich in zijn geheel niet meer druk te maken om niet geminimaliseerde CSS en JS bronnen. Gedurende de bouw van een website, hebben we een nulmeting gedaan van de huidige website. Deze is intussentijd niet veranderd (omdat er een nieuwe site gebouwd werd), maar de meldingen omtrent minimized resources, zijn verdwenen en lijken niet snel impact te hebben op je score.
Ook deze website, waar naast minimalisering van HTML code, ook JS en CSS bronnen worden samengevoegd, en gecomprimeerd om tot een snellere First Contentful Paint te komen, scoort niet slechter wanneer ik dit mechanisme de-activeer binnen het CMS.
Reduce server response time
Alhoewel Google's PSI report nog steeds niet blij wordt van een responsetijd van boven de 0.2 seconden, is de impact minder hoog. Voor diezelfde website -gebouwd in Wordpress- is de score van 69 bij een responsetijd van 0.96, naar 63 gegaan bij een responsetijd van 0.74 seconden. Wanneer de responsetijd even later 0.75 is, is de score 62. Dit staat in verhouding, de eerdere vergelijking niet. Hieruit mag geconcludeerd worden dat de responsetijd-metric van ondergeschikt belang is geworden.
Wellicht is deze factor bijgesteld naar beneden, omdat dit is ondergebracht onder de toegevoegde Speed Score.
Eliminate render-blocking JavaScript and CSS in above-the-fold content
Er wordt zwaarder ingezet op de 'above the fold', of beter gezegd: het optimaal weergeven van hetgeen dat zich boven de vouw afspeelt. Wanneer niet van asynchrone bronnen gebruik wordt gemaakt, kan dit je score om zeep helpen.
Dat hier zwaarder op wordt ingezet, concludeer ik uit het responsetijd-verhouding tussen twee meetpunten. De responsetijd was optimaler geworden tussen twee meetpunten, maar de Optimization score juist lager. Enig andere door de PageSpeed Insights gerapporteerde melding, was "Eliminate render-blocking JavaScript and CSS in above-the-fold content".
Andere websites buiten ons beheer om, die voorheen in de 80% of 90% scoorden, genieten nu ineens lagere scores.
De conclusie en Google's intentie
Of deze verschuivingen blijvend zijn, mag natuurlijk hardop afgevraagd worden. Het is vreemd dat het minimaliseren van bronnen geen rol meer speelt in de suggesties. De verklaring kan zijn, dat Google http/2 ondersteuning gestaag uitgerold ziet worden. Maar alsnog heeft het niet minimaliseren van bronbestanden als gevolg dat er initieel meer kilobytes gedownload worden. Hetzelfde gaat ook op voor het niet opgeven van een cache-duur voor statische bronbestanden (afbeeldingen, javascripts, stylesheets); Dit heeft onnodige requests als gevolg.
Google's AMP project
Ik zie in bovenstaand echter overeenkomsten met Google's AMP project; Een initiatief om webpagina's sneller te laten laden. Dit framework:
- maakt gebruik van meerdere losse JavaScript bestanden, die niet altijd volledig geminimaliseerd zijn en niet aan de oude PageSpeed Insights visie zou voldoen;
- De AMP JavaScript bestanden hebben geen heel hoge cache-duur, een factor dat inmiddels in de PageSpeed Insights report met hooguit 1 procentpunt bestraft wordt;
- De eliminate render block-aspect is belangrijker geworden, juist hetgeen waarop AMP in zijn geheel gebouwd is door CSS direct in het document te embedden.
Dat Google de webdevelopers van tegenwoordig naar AMP wil drukken, staat niet als paal boven water, maar zou een onderliggende reden kunnen zijn. Hoe dan ook kunnen de scores van je website of pagina's dus ineens verschillen ten opzichte van vorig jaar. Test bovenop PageSpeed Insights, je webpagina's dus ook vooral andere pagespeed tools.
Heb ik een update gemist, en heb je meer informatie omtrent deze verschuivingen? Dan hoor ik het graag!
