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.
Websites van onze hand zullen nooit in de buurt komen van een gemiddelde van 60 tot 80 requests (140 is helaas ook geen uitzondering) waarmee Wordpress (als ook Magento, Drupal) websites opgezadeld worden. Echter, de komst van HTTP/2 maakt sommige client side optimalisaties overbodig, maar is dit voldoende?
Website bloat
De komst van HTTP/2 kan voor webbouwers dus een argument zijn om niet meer om te kijken naar performance optimalisatie aan de client kant (html/css/js). Sterker nog, dit zou zware websites, volgeladen met plugins en afbeeldingen enkel in de hand kunnen werken. Servers, netwerken en browsers worden sneller. Waarom zouden we dan juist websites zwaarder maken?
De rol van CMS'en
Een CMS als Drupal en Wordpress genieten de voorkeur door de mogelijkheden van plugins. Dit heeft dus een keerzijde; het neemt zijn eigen bagage mee, en plugins zijn dusdanig out-of-the-box, dat ze niet samenwerken (en dus niet dezelfde bronbestanden benutten). Een twitter-plugin dwingt een bezoeker direct tot het downloaden van allerlei assets, ook nog eens vanuit verschillende domeinen, waar vele requests (afbeeldingen in een twitter stream worden automatisch gedownload) als ook extra DNS-lookups mee gemoeid gaan. Kies dus voor alternatieve plugins, of ontkoppel deze assets.
De grootste factor in website bloat, zijn afbeeldingen. Zet deze dus met mate in, probeer ze vooral te reduceren op landingspagina's (waar snelheid/laadtijd van belang is) en gooi ze door jpg of png compressie tools.
Alternatief is benodigde plugins downloaden, echter met extra geheugen-ballast als gevolg. Dit laatste valt niet onder website-bloat, maar wel voor toename in uitvoertijd op de server en dus langere laadtijd als gevolg.
De rol van Wordpress
Nagenoeg overal lijken plugins voor aanwezig, maar de opsomming van Wordpress plugins zorgt voor toename van andere issues (queries, laadtijd, onderhoud) met gevolgen van dien (kwetsbaarheden, update & upgrade conflicten) en maakt een site in zijn geheel zwaarder (qua PHP geheugen, hier schrijf ik later meer over). Plugins zouden dus wel overwogen en met mate ingezet moeten worden.
Tegelijkertijd neemt met elke plugin de flexibiliteit af om in te springen op nieuwe ontwikkelingen, zonder dat dit impact heeft op hoe zwaar het systeem wordt. Middels ons CMS haken we eenvoudig in op de ontwikkelingen, zonder consessies te hoeven doen op laadtijd, of kwaliteit in zijn geheel.
Te vroeg
Het is dus te vroeg, of wellicht zelfs onrealistisch om de performance-bijl er bij neer te gooien met de komst van HTTP/2, doordat performance en de optimalisatie er van meer doelen dient. Een website kan in praktijk sneller laden doordat browsers en servers onderling geen beperking van het aantal HTTP requests kent. Hooguit neemt voor de bezoeker de laadtijd af. Echter, om enkele concrete aandachtspunten te noemen:
- HTTP/2 geniet beperkte ondersteuning vanuit eerder genoemde partijen (browser en server c.q. website);
- Een zware website zal voor gebruikers onderweg of op vakantie-bestemming, nog steeds een doorn in het oog zijn;
- Performance behelst ook gebruik van CSS en JavaScript, en daarmee ervaring op mobile devices;
- HTTP/2 tackelt geen SEO issues waar bijvoorbeeld een Wordpress mee kampt;
- HTTP/2 tackelt niet automatisch goed gebruik of inzet van CDN's.
Performance optimalisatie vanuit de basis
Wij blijven dan ook vanuit de bron en dus de basis optimaliseren, in plaats van re-actief repareren. Zo hebben we Critical Path CSS als ook AMP reeds geïmplementeerd in ons CMS en blijven we andere features en ontwikkelingen op de voet volgen, waarbij de implementatie zelden arbeidsintensief zal zijn. Ook testen we sites van onze hand graag en passen we wanneer gewenst en waar nodig andere optimalisaties toe.
Komende weken besteed ik in afzonderlijke schrijfsels waar je op kunt letten om bijvoorbeeld requests in te dammen of de performance te optimaliseren (AMP, font gebruik, resource hints). Dit doe ik als tegengeluid tegen website bloat en om meer bewustzijn te creëren rondom website performance (en dus al dan niet de bewuste keuze voor systemen als Wordpress en Drupal).
next up: Wordpress plugins, de afkomst.