Site tuning (WordPress, 2022): verschil tussen versies

Uit De Vliegende Brigade
Naar navigatie springen Naar zoeken springen
Regel 61: Regel 61:
 
Diverse tools geven grafisch weer hoe een laad-evenement precies plaatsvindt. Ik heb die info hier niet paraat, maar ''TTFB'' was rondom een casus in januari 2021, vermoedelijk een centraal begrip: Hoe lang het duurt voortdat de eerste byte binnen is.
 
Diverse tools geven grafisch weer hoe een laad-evenement precies plaatsvindt. Ik heb die info hier niet paraat, maar ''TTFB'' was rondom een casus in januari 2021, vermoedelijk een centraal begrip: Hoe lang het duurt voortdat de eerste byte binnen is.
  
−
== Diagnose-gereedschap ==
+
== Diagnose ==
  
 
Een vrij willekeurige exposé van tools:
 
Een vrij willekeurige exposé van tools:
Regel 73: Regel 73:
 
* [http://gtmetrix.com/ GTmetrix]: In juni 2013 aangeraden door iemand van Internet Today
 
* [http://gtmetrix.com/ GTmetrix]: In juni 2013 aangeraden door iemand van Internet Today
 
* Google Search Console contains stuff.
 
* Google Search Console contains stuff.
 +
 +
In de afgelopen jaren ben ik een paar keer van meetmethode veranderd:
 +
 +
=== WebPageTest (2016-2020) ===
 +
 +
Een paar jaar lang heb ik voornamelijk ''WebPageTest'' gebruikt. Ik weet niet meer waarom. Misschien vond ik de grafiekjes met allerlei kleurtjes wel mooi. Of het feit dat je de resultaten van meerdere ''runs'' kunt samenvatten.
 +
 +
In 2020 werd dit de standaardmethode:
 +
 +
* [https://www.webpagetest.org WebPagetest]
 +
* Mediaan van 9 runs - Als je WebPagetest meerdere keren laat testen, verschijnt bovenaan het scherm de ''mediaan''
 +
* Meet-grootheid: ''First View'' - Dat is hetzelfde als ''Document Complete » Time''
 +
* Locatie: Amsterdam, nl, MeasureWorks
 +
* Browser: Chrome
 +
* Cable.
 +
 +
=== Google PageSpeed Insights (2020) ===
 +
 +
In 2020 gestandaardiseerd op ''Google PageSpeed Insights'', omdat een partij die voor mij de hosting van een aantal webwinkels verzorgt, dit gebruikt als meetmethode. Bevalt prima, maar heeft nadelen:
 +
 +
* Het geeft scores, maar niet de eigenlijke meetwaardes. Soms wil ik gewoon meetwaardes hebben (laadtijden)
 +
* Niet bruikbaar voor pagina's die niet publiekelijk toegankelijk zijn.
 +
 +
=== Page Load Time-plugin (2021) ===
 +
 +
Begin 2021 ben ik deels overgestapt op de [https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig Page Load Time]-plugin voor Google Chrome, omdat deze methode een aantal voordelen biedt boven bv. ''Insights''.
 +
 +
* '''Niet-publieke pagina's:''' Het werkt ook voor pagina's die niet toegankelijk zijn voor externe tools, bv. backend-pagina's van CMS-sites (bv. ''/wp-admin''-pagina's van WordPress-sites) of ontwikkelsites die niet publiekelijk toegankelijk zijn (bv. achter een .htaccess-login). Dit speelde voor mij tijdens een project begin 2021
 +
* '''De essentie:''' Dit is de essentie van waar het om gaat, want dit is wat bezoekers ervaren
 +
* '''Echte getallen:''' Meetwaardes zijn 'real-world-getallen': Het zijn geen abstracte theoretische grootheden waarvan ik eigenlijk niet goed snap wat het inhoudt. Het is gewoon wat ik écht ervaar.
 +
 +
Enkele nuanceringen:
 +
 +
* Er bestaan truuks om een pagina gebruiksklaar te maken nog voordat deze geheel geladen is, zodat het lijkt alsof de pagina sneller geladen is. Ik geloof dat dat oa. ''lazy loading'' wordt genoemd. Dat doet echter geen afbreuk aan het criterium van het meten van de laadsnelheid
 +
* Nadeel van deze zelf-meet-methode: Meetresultaten zijn afhankelijk van de waarnemer: Als ik een site bezoek via een vaste netwerkverbinding op een vaste computer, krijg ik vermoedelijk andere getallen dan wanneer ik meet met een oud mobieltje op een beroerd wifi-netwerk. Dit maakt getallen moeilijk te vergelijken, maar de essentie is prima op orde: Meten tot op de seconde nauwkeuring hoe lang laden doorgaans duurt.
 +
 +
=== Wat ik eigenlijk zoek... ===
 +
 +
Idealiter zou ik een tool hebben zoals ''Page Load Time-plugin'', waarbij ik met een druk op de knop kan aangeven dat ik het resultaat van meerdere runs wil hebben, zodat ik resultaten krijg met daadwerkelijke significante cijfers: Zie verderop in dit artikel voor een klein onderzoekje, waarbij ik bemerkte dat ik na 35 runs, nog steeds geen gemiddelde laadtijd met twee significante cijfers had bereikt.
 +
 +
=== Hoe vaak moet je meten? ===
 +
 +
Meetwaardes kunnen nogal uiteenlopen. Hoe vaak moet je meten om een betrouwbare waarde te krijgen? Wat is een goede methode?
 +
 +
Conclusies:
 +
 +
# Door de extremen te verwijderen, krijg je sneller een betrouwbare score
 +
# Om laadtijden op de seconde nauwkeurig te meten: 5 metingen is behoorlijk betrouwbaar (7 zonder verwijdering extremen). Met 13 metingen krijg je een heel betrouwbaar resultaat (15 zonder verwijdering extremen)
 +
# Om laadtijden op één cijfer achter de komma nauwkeurig te meten: 29 metingen (31 zonder verwijdering extremen)
 +
# Om laadtijden op twee cijfers achter de komma nauwkeurig te meten: Meer dan 35 metingen - Belachelijk veel werk.
 +
 +
Voor details: [[file:how-to-measure-load-times-reliably.ods]]
  
 
== Inventaris ==
 
== Inventaris ==

Versie van 21 jan 2021 11:25

Dit artikel gaat over het optimaliseren van de laadsnelheid, of performance van WordPress-sites, in het bijzonder voor WooCommerce-sites met duizende producten en uitgebreide taxonomieën. Mocht je je afvragen of WordPress wel geschikt is voor dergelijke sites: Er bestaat zelfs een vervanging voor de standaard-database-klasse, om overweg te kunnen met meerdere database-servers - Dit is uiteraard geen garantie dat WordPress geschikt is voor enige specifieke site, maar het geef me vertrouwen dat WordPress serieus wordt gebruikt voor grootse zaken.

Twee geweldige artikelen, als optimalisatie nieuw voor je is:

Het gaat om de laadsnelheid

Er bestaan een hoop tools die op de meest geweldige manieren allerlei fantastische dingen meten. Sommige tools vertalen dat in één of meer tijdwaardes, terwijl andere tools dat vertalen naar scores.

Volgens mij komt het uiteindelijk neer op wat intuïtief de laadsnelheid is. Datgene wat je zou meten, als je met een stopwatch op een 'neutrale plek op het internet' bijhoudt hoe lang het duurt om een pagina te laden: Het is altijd duidelijk wanneer een pagina geladen is, en het is ook altijd duidelijk wanneer het laden is begonnen - Namelijk op het moment dat je op de betreffende knop of link klikt. Dit is ook precies wat bezoekers ervaren.

Kwantitatief

  • Medewerker Internet Today (2016): Alles onder de 2s is ok, maar alles boven de 1,3s moet een goede reden hebben
  • Medewerker Google Partners (2017): Alles boven de 3s is problematisch, en moet je verhelpen.

Wat ik aanhoud sinds 2021 [1]:

  • Max. 2s - Alles hierboven is problematisch en moet verholpen worden
  • Streef naar max. 0,5s.

Google Core Web Vitals

Google heeft een handjevol criteria onder de naam Core Web Vitals. Ik heb niet alle details paraat, maar dit is zo'n beetje wat goede scores zijn:

Entiteit Opmerkingen
TTFB Time To First Byte: 0,1-0,2s
FCP First Contentful Paint [2], [3]
LCP Largest Contentful Paint: Max. 2,5s. Onder 1s is snel
Load time aka. Document complete, Onload time - 1,5-3s

Opmerkingen:

  • De Fully Load Time kan sterk variëren en is afhankelijk van bv. third-party code. Meestal is deze 1-2 seconde hoger dan the Load time. Voor WooCommerce-sites kan dit al snel 3-5s hoger zijn
  • Sommige WooCommerce-pagina's kunnen deze scores niet halen, bv. cart en checkout ivm. verwerking van data.

Backend

Het is moeilijk om iets zinnigs te zeggen over de laadtijden van backend-pagina's (alle pagina's die beginnen met /wp-admin/), omdat deze meestal niet gecached worden en omdat er meer rekenwerk aan te pas komt:

  • Plugin-pagina: Het kan snel 5-20s vergen voor de plugin-pagina om op te bouwen, omdat veel plugins eerst verbinding zoeken met licentie-servers
  • Als je in Screen options hebt ingesteld dat er veel producten of veel orders op een pagina getoond moeten worden, kost dat tijd
  • Richtlijn: 0,8-3s voor backend-pagina's, als er niet iets bijzonders aan de hand is.

Laad-evenement

Diverse tools geven grafisch weer hoe een laad-evenement precies plaatsvindt. Ik heb die info hier niet paraat, maar TTFB was rondom een casus in januari 2021, vermoedelijk een centraal begrip: Hoe lang het duurt voortdat de eerste byte binnen is.

Diagnose

Een vrij willekeurige exposé van tools:

  • Page Load Time-plugin voor Google Chrome
  • Google PageSpeed Insights - Geen laadtijd, maar een rapportcijfer voor mobiel en desktop
  • Webpagetest.org - Alle cijfers en details
  • gtmetrix.com - Aanbevolen in maart 2017
  • Firebug YSlow - Heel aardig, maar geeft geen meetgetal
  • Firebug Page Speed - Heel aardig, maar geeft geen meetgetal
  • GTmetrix: In juni 2013 aangeraden door iemand van Internet Today
  • Google Search Console contains stuff.

In de afgelopen jaren ben ik een paar keer van meetmethode veranderd:

WebPageTest (2016-2020)

Een paar jaar lang heb ik voornamelijk WebPageTest gebruikt. Ik weet niet meer waarom. Misschien vond ik de grafiekjes met allerlei kleurtjes wel mooi. Of het feit dat je de resultaten van meerdere runs kunt samenvatten.

In 2020 werd dit de standaardmethode:

  • WebPagetest
  • Mediaan van 9 runs - Als je WebPagetest meerdere keren laat testen, verschijnt bovenaan het scherm de mediaan
  • Meet-grootheid: First View - Dat is hetzelfde als Document Complete » Time
  • Locatie: Amsterdam, nl, MeasureWorks
  • Browser: Chrome
  • Cable.

Google PageSpeed Insights (2020)

In 2020 gestandaardiseerd op Google PageSpeed Insights, omdat een partij die voor mij de hosting van een aantal webwinkels verzorgt, dit gebruikt als meetmethode. Bevalt prima, maar heeft nadelen:

  • Het geeft scores, maar niet de eigenlijke meetwaardes. Soms wil ik gewoon meetwaardes hebben (laadtijden)
  • Niet bruikbaar voor pagina's die niet publiekelijk toegankelijk zijn.

Page Load Time-plugin (2021)

Begin 2021 ben ik deels overgestapt op de Page Load Time-plugin voor Google Chrome, omdat deze methode een aantal voordelen biedt boven bv. Insights.

  • Niet-publieke pagina's: Het werkt ook voor pagina's die niet toegankelijk zijn voor externe tools, bv. backend-pagina's van CMS-sites (bv. /wp-admin-pagina's van WordPress-sites) of ontwikkelsites die niet publiekelijk toegankelijk zijn (bv. achter een .htaccess-login). Dit speelde voor mij tijdens een project begin 2021
  • De essentie: Dit is de essentie van waar het om gaat, want dit is wat bezoekers ervaren
  • Echte getallen: Meetwaardes zijn 'real-world-getallen': Het zijn geen abstracte theoretische grootheden waarvan ik eigenlijk niet goed snap wat het inhoudt. Het is gewoon wat ik écht ervaar.

Enkele nuanceringen:

  • Er bestaan truuks om een pagina gebruiksklaar te maken nog voordat deze geheel geladen is, zodat het lijkt alsof de pagina sneller geladen is. Ik geloof dat dat oa. lazy loading wordt genoemd. Dat doet echter geen afbreuk aan het criterium van het meten van de laadsnelheid
  • Nadeel van deze zelf-meet-methode: Meetresultaten zijn afhankelijk van de waarnemer: Als ik een site bezoek via een vaste netwerkverbinding op een vaste computer, krijg ik vermoedelijk andere getallen dan wanneer ik meet met een oud mobieltje op een beroerd wifi-netwerk. Dit maakt getallen moeilijk te vergelijken, maar de essentie is prima op orde: Meten tot op de seconde nauwkeuring hoe lang laden doorgaans duurt.

Wat ik eigenlijk zoek...

Idealiter zou ik een tool hebben zoals Page Load Time-plugin, waarbij ik met een druk op de knop kan aangeven dat ik het resultaat van meerdere runs wil hebben, zodat ik resultaten krijg met daadwerkelijke significante cijfers: Zie verderop in dit artikel voor een klein onderzoekje, waarbij ik bemerkte dat ik na 35 runs, nog steeds geen gemiddelde laadtijd met twee significante cijfers had bereikt.

Hoe vaak moet je meten?

Meetwaardes kunnen nogal uiteenlopen. Hoe vaak moet je meten om een betrouwbare waarde te krijgen? Wat is een goede methode?

Conclusies:

  1. Door de extremen te verwijderen, krijg je sneller een betrouwbare score
  2. Om laadtijden op de seconde nauwkeurig te meten: 5 metingen is behoorlijk betrouwbaar (7 zonder verwijdering extremen). Met 13 metingen krijg je een heel betrouwbaar resultaat (15 zonder verwijdering extremen)
  3. Om laadtijden op één cijfer achter de komma nauwkeurig te meten: 29 metingen (31 zonder verwijdering extremen)
  4. Om laadtijden op twee cijfers achter de komma nauwkeurig te meten: Meer dan 35 metingen - Belachelijk veel werk.

Voor details: Bestand:How-to-measure-load-times-reliably.ods

Inventaris

Denk bij optimalisatie zoal aan:

  • Caching - wo. object caching, CDN's & caching-servers zoals Varnish
  • Content offloading
  • Server-optimalisatie: PHP-versie, hardware-specs, db- & php-optimalizatie, meer?
  • Gebruik van meerdere servers
  • Afbeeldingen: WordPress lijkt afbeeldingen niet vanzelfsprekend optimaal te schalen, zoals Drupal dat doet. Daarnaast worden geïmporteerde afbeeldingen gekopiëerd naar meerdere presets, die misschien niet allemaal nodig zijn
  • Taxonomieën: De wijze van implementatie van taxonomieën, kan een flinke impact hebben op de performance van een site.
  • Uploads: Ik vermoed complicaties als duizende afbeeldingen in dezelfde map worden bewaard

Taxonomieën & performance

Tests in de zomer van 2020 wezen uit:

  • Catagorieën lijken geen impact te hebben op performance, zolang je ze niet gebruikt als filters, maar alleen als shopping-pagina's
  • Categorieën hebben een flinke impact op performance, op het moment dat je categorie-filters gebruikt op winkelpagina's
  • Attributes hebben een flinke impact op de performance van winkelpagina's, zelfs als er amper gebruik wordt gemaakt van filters.

Dit was getest met een site met deze specs:

  • 16.000 Producten, 32.000 afbeeldingen
  • 500 hoofdcategorieën (?)
  • Duizenden kenmerken (?)
  • Geen posts en misschien vijf gewone pagina's

Afbeeldingen - Originele bestanden te zwaar?

Is 111kb acceptabel voor een afbeelding van 892x902? Naast het origineel, het bewerkte exemplaar, dat nog maar 20kb groot is. Ik denk dat het antwoord duidelijk is

WordPress lijkt originele afbeeldingen niet te verkleinen, en als zodanig te gebruiken (of ik gebruik geen afbeeldingen die zo bizar groot zijn, dat WordPress ze aanpast). Voorbeeld van zo'n afbeelding (jpg):

  • 892x902
  • 111k.

Is 111k een redelijke grootte voor een bestand van 892x902? Ik denk van wel, maar ik kon het antwoord zo snel niet online vinden. Een manier om te checken: Op imgonline.com zo'n afbeelding uploaden, en reduceren tot 20k, met behoud van de resolutie

Afbeeldingen - Alle presets relevant?

Als je afbeeldingen upload, worden naast de originele afbeeldingen, nog een aantal presets gegenereerd. Afhankelijk van het soort site, kan dit aantal variëren. Een standaardsite heeft er al snel vier: 

* thumbnail      150 pixels vierkant
* medium         300 pixels breed
* medium_large   768 pixels breed
* large          1024px pixels breed

Voorbeeld van een webwinkel, waarin er blijkbaar zeven presets zijn: 

2,9k  - image-01-100x100.jpg
4,8k  - image-01-150x150.jpg - Thumbnail
13k   - image-01-298x300.jpg
14k   - image-01-300x302.jpg - Medium
23k   - image-01-440x443.jpg
36k   - image-01-600x604.jpg
51k   - image-01-768x773.jpg - Medium_large
111k - image-01.jpg - 892x902 (afmetingen variëren enigszins)

Merk op dat Large ontbreekt. Vermoedelijk omdat de geüploade afbeelding kleiner is dan dat formaat.

Uitbesteden

Geen zin om dit zelf te doen? Te moeilijk? Weet niet? Overig? Ongetwijfeld kan dat. In de loop van 2020 heb ik een enkele keer terloops online gezocht naar specialisten op dit vlak, maar zonder overtuigende resultaten. Hierbij opnieuw een poging. Het is nu januari 2021

Algemeen & intermediairs

WooCommerce-specialisten, maar niet per se performance-specialisten

Specialisten

Fiverr:

Zie ook

Bronnen

Overgenomen van "https://wiki.devliegendebrigade.nl/index.php?title=Site_tuning_(WordPress,_2022)&oldid=25236"