Pagespeed: zo score je 100% met Joomla

banner joomladagen

Als je mijn Joomla performance tutorials een beetje hebt gevolgd, dan heb je misschien al best hoge scores in tools als Pingdom en GT-Metrix, maar 100% halen is behoorlijk lastig, zeker in Google's eigen Pagespeed Insights tool...

Vooral die laatste paar procentjes kunnen het erg lastig maken om die 100% score te behalen. En mogelijk lukt het je in Pingdom of GT-Metrix, maar in Google Pagespeed Insights krijg je dan vaak nog maar iets als 85%. Frustrerend he? Nou, het kan gelukkig wel. Vaak hoor je dat je hiervoor eigenlijk een hele kale site moet gebruiken, maar dat hoeft echt niet. Ook met een mooie aantrekkelijke site kom je er uiteindelijk wel. Ik heb het zelf op deze site voor elkaar gekregen met een standaard Rockettheme template die ik heb uitgekozen om het mooie ontwerp. Wat helpt is het Gantry 5 framework waar de template op draait, die een stuk sneller is dan Gantry 4. Intussen heb ik, inclusief Google Analytics best een leuk resultaat:

pagespeed 100 procent

Hoe heb ik dit nu voor elkaar gekregen? Nou, ten eerste heb ik natuurlijk de voor de hand liggende zaken netjes opgelost, zoals ik die heb behandeld in mijn performance tutorials: Plaatjes netjes comprimeren, efficient gebruik van Javascript en CSS, caching, gebruik van een Content Delivery Network, enzovoorts. Ook gebruik ik de plugin JCH-Optimize om me bij deze zaken te helpen. Ik ga deze stappen hier niet allemaal herhalen, maar ik concentreer me op die laatste stapjes om van 85% naar 100% te komen. Laten we ze eens 1 voor 1 behandelen:

Joomla Hosting tip: Siteground

Joomlaseo.com laadt in 0.5 - 1 seconden en heeft een Pingdom score van 100%!!! Daarom bevelen we Siteground hosting aan. Snelle servers, goede support, gratis SSL, etc. En niet duur...

 

Webfonts van Google en andere bronnen

Alle bronnen voor je website die je niet volledig controleert (lees: laadt vanaf je eigen site) kunnen problemen geven. Dit geldt bijvoorbeeld voor sociale buttons en scripts, maar dus ook voor webfonts. Webfonts implementeren is supermakkelijk, je gebruikt gewoon een stukje code van Google om ze te embedden en klaar is Kees. Echter, deze fonts hebben een korte levensduur, en je kunt ze slecht in de browser hergebruiken, ze moeten steeds opnieuw worden geladen vanaf Google. Eigenlijk is de enige manier om het probleem te omzeilen ze domweg niet te gebruiken... Zo gebruik ik op deze site het Muli font. Dat kun je van Google Webfonts halen, maar je kunt het ook van Font Squirrel halen, de fonts op je eigen site zetten en met @fontface embedding laden. Gevorderde gebruikers kunnen het font zelfs base-encoden, en ze direct in CSS laden. Ik had zelf mazzel, het Muli font was het standaard font van mijn template, en ik hoefde er niets voor te doen, het was al als lokaal font beschikbaar.

Google Analytics

Analytics geeft je hetzelfde probleem als je webfonts, maar het is wat lastiger op te lossen. Mijn oplossing is iets wat Google eigenlijk afraadt: het script lokaal draaien. Google raadt dit af, omdat je mogelijk updates mist en het niet optimaal werkt, maar omdat ik Analytics alleen gebruik voor simpele analyses ben ik daar niet zo bang voor. Ik heb het analytics.js scripts simpelweg gedownload en op mijn eigen server gezet. Vervolgens heb ik de Analytics code simpelweg aangepast om mijn eigen versie te gebruiken::

<script>
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','https://cdn.joomlaseo.com/simon/analytics.js','ga');
   ga('create', 'UA-16857461-24', 'auto');
   ga('send', 'pageview');
</script>

Een andere oplossing die ik wel eens heb gebruikt en die werkt is deze: www.thejunkland.com/blog/fixing-last-point-on-google-pagespeed-insights.html.

Prioritize visible content

Zelfs al je al je andere issues hebt opgelost blijf je in Pagespeed maar tegen dit probleem aanlopen, wat er puur op zich al verantwoordelijk voor is dat je niet boven de 90% scoort:

render blocking

Wat Google ons hier probeert te vertellen is dat ze willen dat je een kritische portie uit je CSS extraheert, namelijk dat deel wat verantwoordelijk is voor het weergeven van de content boven de vouw. Dit deel moet je dan inline in je HTML stoppen, terwijl je de rest van de CSS wel extern laat laden, maar pas nadat de HTML volledig is geladen, dus voor de afsluitende Body tag. Dit is in contrast met de vroegere best-practice om HTML volledig te scheiden van je CSS. Maar Google geeft tegenwoordig voorrang aan performance, en wil dus dat je het zo oplost.

Dat klinkt allemaal knap ingewikkeld, maar zoals bij alles is hier een plugin voor, namelijk mijn geliefde JCH-Optimize In de Pro-versie van de plugin vind je daar de optie Optimize CSS Delivery, die precies dit probleem probeert op te lossen. Je geeft het aantal HTML elementen op waarvoor je de CSS inline wilt laden, experimenteer gewoon met deze waardes, dat valt vantevoren niet te zeggen. In mijn geval is 200 prima:

optimize css delivery

Na hetaanzetten van deze optie had ik eindelijk een Pgespeed score van 100% (check het maar), net zoals ik al heb in Pingdom en Y-slow. Alleen in GT-Metrix heb ik 'maar' 97%,maar dat komt omdat het een kleine desktop emuleert, en sommige plaatjes iets binnen hun container in elkaar gedrukt worden, ik zou dan voor die schermgrootte aparte plaatjes moeten gebruiken, maar dat los ik mogelijk later nog wel eens op.

Bedenk trouwens dat het behalen van een 100% score helemaal geen noodzaak is, het is eigenlijk geneuzel voor freaks... Als je boven de 80% scoort heb je eigenlijk al een prima site.

Over deze site

Joomlaseo.com is volledig gebouwd en geschreven door Simon Kloostra, SEO Specialist en Webdesigner uit Utrecht. Ik heb ook een boek geschreven en blogs voor bedrijven als OStraining, TemplateMonster, SEMrush en dergelijke.