Wij delen als webbouwers graag onze kennis, door onderzoek te doen, code te delen en te schrijven over onze USP's, waaronder snelheid/pagespeed, online duurzaamheid, privacy en digitale toegankelijkheid.
Hopelijk met niet teveel technische abracadabra, maar wél bruikbare tips!😉
"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.
Ook wanneer performance je aan het hart gaat of een WPO-er bent, is de kans aanwezig dat niet alleen jouw online concurrent, maar ook jij performance optimalisatie verkeerd doet. Twee handenvol kenmerken:
Google's PageSpeed Insights is één van de vele tool-sets die een gemiddelde frontend developer tot zijn arsenaal rekent. Hopelijk hoorde Google's Lighthouse daar ook reeds bij. Lighthouse is een Google extensie dat vanuit de browser (DevTools), command line of als node module gedraaid kan worden. Het geeft middels scores vervolgens inzicht in onder meer de performance, accessibility en SEO.
Vanuit ons netwerk merken we dat stappen ondernomen worden om geleidelijk voor te bereiden op de Algemene Verordening Gegevensbescherming (AVG) wetgeving. Voor de ene situatie eenvoudiger dan de andere. Voor websites welke als online visitekaart en informatieverschaffing fungeert, kan het op het eerste gezicht vrij overzichtelijk zijn, maar schijn kan bedriegen!
Vanuit ons netwerk ontvingen we de vraag of een 100% pagespeed op Wordpress basis mogelijk was, waarbij de snelheid als ook gebruikerservaring optimaal bleef, en niet enkel gemeten werd middels een getal.
De oplettende 'Google Watcher' of actieve PageSpeed tester heeft het ongetwijfeld al ontdekt, Het uiterlijk en daarmee ook metrics van PageSpeed Insights zijn gewijzigd. Voornaamste wijziging lijkt de toevoeging van pagespeed, maar er speelt meer.
Eén van de meer lastige onderdelen van een 100% score in Google's PageSpeed insights, is het uit de weg ruimen van de "Eliminate render-blocking JavaScript and CSS" melding die Google soms afgeeft.
Een CMS zorgt voor dynamische invulling voor zijn webpagina's, maar deze dynamiek gaat logischerwijs ten koste van de uitvoertijd, en daarmee tevens de zogenaamde Time To First Byte. Des te meer taken het CMS uit moet voeren om de door je bezoeker opgevraagde content te genereren, des te langer het duurt voordat de eerste byte door je bezoeker zijn of haar browser ontvangen is.
Naar aanleiding van een ouder artikel omtrent de behaalde laadtijd als ook pagespeed score van het LightBolt CMS, ontvingen we de vraag wat LightBolt beter maakt dan een CMS als OctoberCMS, met Laravel als basis. Diezelfde vergelijking gaat in de basis ook op met bijvoorbeeld Wordpress, Magento of Drupal.
Wordpress plugins te over om je website sneller en beter te maken. Zo ook om je Wordpress pagina's AMP te maken. Dit blijkt een noodzaak, doordat AMP een Wordpress pagina beduidend sneller kan maken.
Tot dusver is er veel gezegd over frontend / client side optimalisatie, oftewel het reduceren en/of samenvoegen van http requests als ook bronnen. Maar ook verder onder de motorkap valt er vaak uitstekend te optimaliseren en dus winst te behalen. Afhankelijk van de afwikkeling, zal HTML pas in de browser terecht komen, als de code onder de motorkap klaar is met zijn taak.
Vanaf Wordpress versie 4.6, voegt Wordpress automatisch resource hints toe aan de broncode van je website. Dit lijkt echter zonder enig beleid te gebeuren. In dit artikel tref je dan ook een praktijk-voorbeeld omtrent resource hints, van hoe het niet moet.
Het grote voordeel van Wordpress, is direct ook zijn nadeel. Uiteraard hebben we het dan over plugins, hoe verrijkend zijn ze en voor wie? Een beknopte inzage in de kanttekeningen vanuit de bron.
Zowel de hoeveelheid, mogelijkheden, als ook grootte per stuk van plugins, groeien als kool. Daarmee ook de website resources en dus de laadtijd. Neem de veelvoud en grootte van afbeeldingen mee, en je hebt website bloat.
Vijftig tot wel honderden bestanden, terwijl de browser 6 tot 8 requests tegelijk af kan handelen. Dit betekent een lange laadtijd van je website voor je bezoekers. HTTP/2 maakt dit verleden tijd.
Met regelmaat krijg ik de vraag toegespeeld om een inlogomgeving of webapplicatie in andere vorm, te realiseren middels Wordpress. Doordat Wordpress voor mij echter enkele kanttekeningen heeft, realiseer ik maatwerk applicaties van dit kaliber niet middels Wordpress.
Dagelijks krijg ik te maken met willekeurige 404 meldingen en dus verwijzingen naar niet bestaande interne pagina's, zo lijkt het op het eerste gezicht. De veelvoud aan deze meldingen hebben echter een andere oorzaak die gezocht moet worden in de hacking-wereld.