Wat betekenen front-end optimalisaties nou eigenlijk?

In m’n vorige blogpost schreef ik over hoe ik met een aantal aanpassingen een perfecte pagespeed score van Google kreeg. Leuk om te halen, maar na een paar dagen begon het te knagen. Wat had ik nou eigenlijk gedaan? Ik had een vaag idee dat de aanpassingen er voor zorgden dat de time to screen heel snel werd, maar hoe snel? En was dat meetbaar? Al snel merkte ik dat het zoeken naar de juiste cijfers nogal verslavend is. Of zoals Wiep het mooi zei:

Hier was ik inmiddels al een eind onderweg naar een goed antwoord, maar dat begon allemaal met het zoeken naar de juiste testopzet. Ik wilde dus een site testen. Meerdere malen, zodat ik beter trends kon zien. En (volledig) geautomatiseerd. Al snel kwam ik uit op PhantomJS, een webkit browser zonder voorkant. Er bleken een aantal scripts te zijn om sites te testen: YSlow for PhantomJS, Confess.js, Loadreport en Phantomas. Na testritjes met deze scripts gemaakt te hebben bleek Phantomas het best te passen bij m’n wensen. Ik kon meerdere malen een site testen, en de testresultaten (103 stuks) konden worden weggeschreven naar een json bestand. Nice!

Hoe te testen?

Voor de tests nam ik vier statische versies van m’n homepage:

  1. Het origineel, zonder optimalisaties;
  2. Een geoptimaliseerde versie 1 voor een 100/100 score;
  3. Versie 2 maar jQuery staat lokaal en wordt niet meer van Google CDN gehaald. Dit scheelt ook een request omdat ik het samenvoeg met m’n eigen javascript;
  4. Versie 3, maar modernizr staat inline in de header. Deze heb ik toegevoegd naar aanleiding van deze discussie. Ook dit scheelt weer een request.

Elke site heb ik 8 keer getest, en de resultaten heb ik gevisualiseerd met Google Charts. Ik laat hieronder niet de resultaten van alle 103 tests zien, maar heb voor front-end optimalisatie de belangrijkste er uit gelicht. Ik gebruikte de standaard resolutie van Phantomas: 1280 x 1024.
Update: Zoals Arno in de reacties al opmerkte gebruikt Phantomas geen cache, en haalt jQuery elke keer opnieuw op.

De resultaten

Alle HTML is gedownload en is geparsed. Dit gebeurt voordat de pagina is getekend. Javascript kan hier worden uitgevoerd. Wat direct opvalt is het verschil tussen het origineel en de optimalisaties: die is met ongeveer een factor 40 sneller geworden! De site is dus veel sneller klaar om getekend te worden, dus een veel snellere time to screen.

Alle afbeeldingen en scripts zijn gedownload, het laadicoontje in je browser houdt hier op met animeren. Versie twee is duidelijk langzamer dan het origineel, en dat is niet best. Maar versie drie en vier maken deze test meer dan goed. Hoe komt dit? In versie twee download ik jQuery van Google CDN, en uit tests bleek dat dit wel een seconde kon duren. Daarom staat jQuery nu lokaal, en je ziet het resultaat van het weghalen van die ene seconde. Het is me trouwens een raadsel waarom dat in versie een niet zo was.

De browser weet hoe de pagina er uit gaat zien, ook al zijn alle afbeeldingen en scripts nog niet gedownload. Ook hier is het resultaat van het weghalen van blokkerende css en scripts overduidelijk.

Net zoals bij de Window Onload test is hier het lokaal zetten van jQuery ook een hele goede optimalisatie. Het zijn maar acht tests, maar volgens mij geeft dit wel aan dat het inlinen van modernizr er juist weer voor zorgt dat deze test wat langer duurt.

De conclusie

M’n vermoedens zijn bevestigt, en ik denk dat de cijfers dat laten zien. De grootste optimalisatie is toch het asynchroon laden van stylesheets en scripts. jQuery lokaal zetten maakt heel veel uit voor de window onload. En daarna zijn er nog milliseconden vanaf te schrapen met kleine tweaks. Ik denk dat versie 3 de beste optimalisatie is; door alle tests heen laat deze de beste cijfers zien.

Wat vinden jullie? Heb ik een belangrijke test niet uitgelicht? Heb ik cijfers verkeerd geinterpreteerd? Laat het weten in de reacties.

Update 2: het inlinen van modernizr haalt de pagespeed score weer omlaag.

6 Reacties

  1. Gebruikt je Phantomas setup ook een soort cache? Want het hele idee van jQuery via de Google CDN is natuurlijk dat er een goede kans is dat het script al in de cache van de bezoeker staat. Dat maakt waarschijnlijk nogal wat verschil in je tests!

  2. Ja, daar heb je gelijk in, en dat was ook de reden dat ik jQuery via Google binnenhaalde. Ik denk – al weet ik nog niet zeker- dat Phantomas niet cached. Als jQuery wel gecached zou zijn dan kan de ene seconde van test twee af, en zal die veel meer op nr. drie gaan lijken.

  3. Hij zal misschien zelfs sneller zijn. jQuery kan dan uit de cache geserveerd worden, terwijl hij lokaal eerst nog opgehaald zou moeten worden.

  4. Ik heb een opmerking toegevoegd dat de test geen cache gebruikt.

  5. Cool is dit! Ik ben benieuwd: Zijn er plugins die je gebruikt?
    Het viel mij bijvoorbeeld op dat Contact Form 7 op elke pagina zijn scripts laadt. Ik heb daar dus een extra scriptje voor moeten schrijven om te zorgen dat dit alleen geladen wordt op de contact pagina.

    Heb je dus voor die plugins of dingen als Google Webfonts ook bepaalde optimalisatie maatregelen toegepast?

    1. Thanks! Ik heb geen plugins gebruikt, daarmee zou dit verhaal denk ik ook niet werken. Of iemand moet er een plugin voor schrijven. 🙂
      Google webfonts kun je het beste op je eigen site zetten, en niet van Google halen.

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *