Ondanks het feit dat heden ten dage onze projecten voor 90% uit maatwerk webapplicaties bestaan, is de affiniteit voor puur frontend development in zijn breedste zin intact gebleven. Reeds in 2005 hield ik mij bezig met de semantiek van HTML; tabellen voor layout-doeleinden was tot dat moment hèt middel, maar uiteraard not-done.
De ontwikkelingen en aanbevelingen staan echter nog steeds niet stil. Toentertijd beperkte ik bestandsgrootte en -requests reeds tot een minimum en verschuivingen in technieken als sprite images in plaats van pre-loaders en later font/icon-files in plaats van afbeeldingen voor iconen werden door mij geadopteerd.
Deze passie voor frontend development en de technische kant van SEO, werd recent weer aangewakkerd door een opdracht die ik namens de Sales Force afdeling van Nuon mocht realiseren. Waar in het geval van een applicatie de server side performance en vooral functionaliteit een rol speelt, speelt bij publieke websites de client side performance en hoe snel de informatie voorgeschoteld kan worden, een rol.
De gebreken van Google's PageSpeed Insights tests
SEO zou natuurlijk al optimaal moeten zijn bij de bron, voordat je met alternatieven begint. Dit lijkt echter vaak (met name in het geval van Wordpress sites) een onbekend feit of ondergeschoven kindje (wegens kennisgebrek, arbeidsintensiviteit ten opzichte van het project-budget of beperkingen in thema's/plugins). En alhoewel mijn bevinding is dat de PageSpeed Insights test een goede graadmeter is, geeft het geen beeld van de website als geheel en kunnen minimale kinken in de kabel, voor slechte scores zorgen.
- individuele bestands-test
meerendeel van de beoordelingen vinden op individueel bestands-niveau plaats, en zegt dus niets over de algehele performance van de website; - externe bronnen
voorschotelen van (stylesheet/javascript/media) bestanden (waaronder ook externe trackers) worden beoordeeld op de mogelijkheid om gecached te worden door de bezoeker. Vreemd genoeg struikelt de PageSpeed Insight van Google, over een eventuele Analytics snippet... van Google. Kortom, op cache-duur of compressie van externe bronnen heb je als bouwer geen invloed. - above the fold / critical path css
Met andere woorden: lever kritieke CSS -verantwoordelijk voor de bovenkant van de website- zo snel mogelijk aan, direct in het html-document. Ook over een langzame internet verbinding kan de bezoeker alvast de opgevraagde content raadplegen, terwijl overige visuele onderdelen onder de vouw nog geladen worden.
De PageSpeed Insights test van Google, eist echter een gelijk ogende above-the-fold gedeelte (op basis van de Critical Path CSS) en het uiteindelijke resultaat. Als webbouwer of UX-designer kun je echter prima van mening zijn, dat bepaalde knoppen nog niet in beeld hoeven te staan wanneer de browser voor het eerst begint met invullen van je beeldscherm.
Een goede score met een zware site
Het is mogelijk om met een zware site, een goede score van boven de 90% te behalen, ook met Wordpress. Dit is mogelijk doordat het controle-mechanisme van Google's PageSpeed Insights verschillende bronbestanden individueel lijkt te beoordelen. Kijk je echter dieper, dan valt het volgende op:
- Er wordt gebruik gemaakt van minimaal 80 requests
de huidige pagina die je leest, tikt de 15 niet eens aan, onze nieuws-overzichtspagina kan het af met 7 requests); - Voorgeschotelde bronnen, komen van 30 verschillende domeinen
Dit heeft dan ook als gevolg, dat er een connectie door de browser moet worden opgezet, om externe bronnen binnen te halen. Dit vergt een DNS lookup per domein. Vanuit performance oogpunt zou je DNS Lookups moeten reduceren. Bovendien heb je geen invloed op hoe andere domeinen, de bronbestanden serveren (gecomprimeerd en wel of niet voorzien van de juiste headers); - Er worden 7 font/lettertype files ingeladen
Custom fonts zijn niet meer weg te denken. Font files voor iconen ook niet. Zeven verschillende fontfiles is echter een absurd aantal; - Diezelfde fonts, staan in de Critical Path
Maar dit registreert Google niet. De PageSpeed Insights achterhaalt dus enkel of de Critical Path CSS voldoende is, maar niet of er wellicht een overvloed aan CSS (en dus verplicht te downloaden kilobytes) is; - Caching wordt niet optimaal benut
Dezelfde font-embedding als ook JavaScript, komt op elke pagina terug. Dit druist niet enkel in tegen de webrichtlijnen: Doordat het geen one-page website betreft, wordt een bezoeker opgezadeld met extra kilobytes per page-hit, welke prima gecached kunnen worden. In plaats daarvan worden de eigenlijke HTML documenten zwaarder gemaakt;
* In sommige punten, zou http/2 een oplossing zijn, maar is niet altijd beschikbaar
Een slechte score met een technisch goede site
Andersom is het mogelijk om met een technisch goede site, geen 100% score te behalen. Zelfs wanneer je Critical Path CSS probeert te implementeren, een uitdaging op zich. Wanneer de above-the-fold gedeelte bij de eerste indruk geen overeenkomstig uiterlijk heeft als het eindresultaat, zal Google je geen 100% score gunnen. Dit geldt ook wanneer je gebruik maakt van Google Analytics, of eigenlijk zelfs externe bronnen in het algemeen, zoals in bovenstaand voorbeeld geïllustreerd wordt. Voor een 100% score, moet je dus al bijna afstand nemen van alle externe bronnen (zoals trackers en widgets).
Waar is een PageSpeed Insights test dan wel goed voor?
De PageSpeed test van Google geldt dus als een algemeen advies. Je kunt makkelijk ontdekken of je een veelvoud aan externe bronnen hebt, en of ze al dan niet naar wens geserveerd worden. Ook valt na te gaan of het above-the-fold gedeelte goed geserveerd wordt, waarmee een unieke bezoeker alvast uit de voeten kan. Niet geminimaliseerde of gecomprimeerde bronbestanden zullen ook aangekaart worden, als ook reactie-tijd van de server.
De mate waarin je dit in de wind slaat, of juist wel aan de slag gaat met deze PageSpeed Insights adviezen, zal afhangen van de mate waarin laadtijd en performance in het algemeen een rol speelt. Optimalisatie, laadtijden en daarmee ook SEO, gaat echter verder dan dat.
PageSpeed alternatieven
Naast Google's eigen PageSpeed Insights tool om websites te testen, maak ik ook graag gebruik van andere bronnen. Waaronder:
Vooral laatst genoemde geeft meer waardevolle informatie dan een test in PageSpeed Insights. Als aanvulling op PageSpeed Insights kaart een test op gtmetrix.com ook CDN, Cookie, Headers (Expires/ETag) issues en bijvoorbeeld CSS @import en expressies (die je moet vermijden) aan. Ter illustratie, dezelfde pagina getest in gtmetrix.com. Hieronder de score van deze pagina:
Daarnaast kan zonder een webdeveloper toolbaar in te hoeven schakelen, achterhaald worden hoeveel requests er gemoeid gaan met het laden van een pagina, als ook hoeveel kb's of zelfs mb's er mee gemoeid gingen, en hoe je scoort in verhouding tot het gemiddelde.
Combinatie van tests is de oplossing?
Grotendeels, want zelfs dat geeft je niet alle informatie. Je verkrijgt hiermee wel een zeer stevig advies over wat aangepakt zou moeten worden. Of eigenlijk, aangepakt zou kunnen worden: Een gtmetrix.com test van deze pagina, geeft bijvoorbeeld aan dat er een CDN ingezet zou moeten worden voor statische bestanden. Oftewel, een externe leverancier/domein voor bijvoorbeeld afbeeldingen en javascript-bestanden. Bewust noem ik geen stylesheets, deze zouden zo snel mogelijk in het bezit moeten zijn van de bezoeker. Daarbij zou idealiter geen vertragende DNS lookups aan te pas moeten komen.
Deze site maakt overigens wel degelijk gebruik van een CDN (zie screenshot), te weten:
- fonts.gstatic.com om een specifieke lettertype op te halen;
- cdnjs.cloudflare.com om een jquery-file als ook een plugin voor het openen van foto's (fancybox) op te halen.
Vooral deze laatste is dusdanig ingezet, dat meerdere bestanden over éénzelfde CDN worden geserveerd, om de eerder genoemde DNS lookups beperkt te houden. Ook een onderdeel van snelheid/performance optimalisatie:in tegenstelling tot de eerder genoemde 30 verschillende domeinen, reeds tot stand gekomen verbindingen juist benutten.
