WordPress-snelheid optimaliseren: de gevorderde technieken

Inleiding: dit artikel begint waar de andere ophouden

Prestatiegidsen zeggen allemaal hetzelfde: zet een cache aan, comprimeer uw afbeeldingen, gebruik een distributienetwerk. Dat klopt, dat is nodig, en zodra het gedaan is, zijn de meeste sites nog steeds traag.

Dit artikel neemt die drie als gegeven. Het behandelt wat overblijft — en dat zit vrijwel nooit in het renderen van de pagina:

totale tijd = servertijd + kritiek pad + wat derde partijen toevoegen
                   ↑           ↑                    ↑
            query's, PHP   blokkerende        scripts die u
            autoload, cron  CSS/JS            niet hebt geschreven

De gidsen behandelen de middelste kolom. De andere twee zijn waar de seconden zitten. Voor de basis en het meten van de Core Web Vitals begint u met het optimaliseren van de Core Web Vitals.

1. De servertijd — wat de cache verhult in plaats van oplost

Een paginacache maakt het probleem onzichtbaar voor anonieme bezoekers en laat het volledig intact voor alle anderen: ingelogde gebruiker, gevulde winkelwagen, accountpagina, interne zoekfunctie, formulieren. In een webshop zijn dat precies de pagina's die geld opleveren.

De optietabel en autoload. WordPress laadt bij elk verzoek alle opties die als automatisch geladen zijn gemarkeerd. Verwijderde extensies laten daar vermeldingen achter, soms omvangrijke, die voor altijd blijven worden gelezen. Het is de eerste plek om te kijken en vrijwel niemand doet het: meet het totale gewicht van de autoload, en vervolgens waaruit die bestaat.

Niet-geïndexeerde query's. Een query die een hele tabel doorloopt, is pijnloos bij duizend rijen en fataal bij honderdduizend. Het symptoom misleidt: de site wordt geleidelijk traag, men wijt het aan de hosting, en de oorzaak is een query die nooit is veranderd.

De geplande taken. WordPress start ze bij het laden van een pagina — een bezoeker betaalt de uitvoering. Een zware taak op een site met weinig verkeer geeft het slechtste geval: de enige bezoeker van het uur wacht op de back-up. Overstappen op echte serverplanning is een van de meest rendabele ingrepen uit deze lijst.

Het aantal extensies. Het is geen mythe: elk voegt optielezingen, scripts en aanhaakpunten toe. Van dertig naar vijftien gaan is zichtbaar in de servertijd zonder enige andere ingreep — zie uw extensies in 5 stappen auditeren.

2. Het kritieke pad — de enige regel die telt

Alles wat de weergave van het eerste scherm blokkeert, is tijd waar de bezoeker naar kijkt. De klassieke technieken (minificeren, uitstellen) lopen snel tegen een plafond. Wat werkelijk deblokkeert:

• laad wat het eerste scherm nodig heeft, stel de rest uit. Eén CSS-bestand met de stijlen van alle pagina's laat de startpagina betalen voor de opmaak van het afrekenproces;
• laad scripts niet waar ze niet dienen. Een contactformulier dat zijn bibliotheek op alle 400 pagina's laadt, komt buitengewoon vaak voor, en de oplossing is voorwaardelijk: laden op de pagina die het gebruikt;
• reserveer de ruimte voor elementen die later komen. Een banner, een afbeelding, een lettertype dat zich invoegt verschuift de pagina — de bezoeker raakt zijn regel kwijt, en de maat voor visuele stabiliteit stort in. De hoogte reserveren kost één stijlregel;
• laad het lettertype en de afbeelding van het eerste scherm vooraf, maar alleen die. Alles vooraf laden staat gelijk aan niets prioriteren.

⚠ De valkuil: optimaliseren wat het meetgereedschap toont in plaats van wat de bezoeker ervaart. Een score die u haalt door een script uit te stellen dat drie seconden later nodig is, heeft niets verbeterd — hij heeft het wachten buiten de meting geschoven.

3. De derde partijen — de zwaarste post en de minst bekeken

Op veel sites komt de helft van de laadtijd uit code die niemand in het bedrijf heeft geschreven: bezoekmeting, toestemmingsbanner, chat, advertentiepixels, externe lettertypen, kaarten.

Drie regels, op rendement:

1. Tellen vóór discussiëren. Noteer elk script van derden en wat het toevoegt aan gewicht en tijd. Het resultaat verrast, en het maakt het gesprek mogelijk met wie erom vroeg.
2. Een derde partij moet haar plaats verdienen. Een pixel geplaatst voor een campagne die acht maanden geleden eindigde, kost elke dag. Het is de snelste en meest rendabele opruiming van dit hele artikel.
3. Zelf hosten wat kan. Lettertypen in het bijzonder: ze vanaf uw eigen domein serveren haalt een naamopzoeking, een verbinding en een beveiligingsonderhandeling weg — en lost onderweg een kwestie van persoonsgegevens op.

Het geval van de toestemmingsbanner is het lastigst, want die is verplicht en komt vroeg. De oplossing is niet hem weg te halen, maar hem in te voegen zonder dat hij de pagina wegduwt. Behandeld in onze aanpak van toestemming en cookies.

4. De afbeeldingen — voorbij de compressie

Compressie is een gegeven. Wat overblijft:

• de geserveerde afmetingen. Een afbeelding van 2400 px getoond in een kader van 600 px verstuurt vier keer te veel bytes. Het is de meest voorkomende verspilling na de derde partijen;
• het formaat, gekozen naar inhoud en niet uit principe;
• uitgesteld laden, behalve voor de afbeelding van het eerste scherm. Die uitstellen verslechtert rechtstreeks de hoofdmaat — de klassieke fout van het overal aangevinkte vakje;
• de alternatieve teksten, die de snelheid niet dienen maar die u meteen kunt meenemen nu u het onderwerp opent. Zie onze vergelijking tegenover Smush.

5. Meten — drie fouten die u voor niets laten werken

Alleen in het laboratorium meten. Een synthetische test vanuit een nabij datacentrum op een perfecte verbinding beschrijft niemand. Veldgegevens beschrijven uw bezoekers.

Naar het gemiddelde kijken. Het gemiddelde verbergt de staart van de verdeling, en in de staart zitten de afhakers. Kijk naar de hoge percentielen: dat zijn uw klanten op een telefoon, onderweg.

Eén pagina meten. De startpagina is zelden representatief. Meet een contentpagina, een productpagina en het afrekenproces — drie profielen, drie knelpunten.

En de enige vraag die het geheel beslecht: is het conversiepercentage bewogen? Een snelheidswinst die op geen enkele zakelijke maat zichtbaar is, is een ingenieurswinst. Voor een webshop staat de volledige redenering in de optimalisatie van de conversietrechter.

6. Het gevorderde protocol, op één pagina

• Vooraf meten — veld en laboratorium, op drie paginatypen, en de getallen noteren
• Gewicht van de autoload vastgelegd, verweesde vermeldingen van verwijderde extensies opgeruimd
• Trage query's opgespoord op de traagste pagina, niet op de startpagina
• Geplande taken overgezet naar echte serverplanning
• Inventaris van derde partijen, met per stuk: wie vroeg erom, waarvoor, nog nuttig?
• Lettertypen zelf gehost, vooraf geladen, en alleen die
• Voorwaardelijke scripts: geladen op de pagina's die ze gebruiken
• Ruimte gereserveerd voor elk element dat na het renderen invoegt
• Opnieuw meten, vergelijken met de genoteerde getallen, en een onaangeroerde controlepagina bewaren

Conclusie

Zodra cache en compressie staan, wint u snelheid niet meer met instellen: u wint haar met weghalen. Opties die voor niets worden geladen, scripts die één op de vierhonderd pagina's bedienen, derde partijen geplaatst voor een afgelopen campagne, extensies bewaard voor het geval dat.

Het is minder spectaculair dan een nieuwe cachemodule, en het is wat de seconden oplevert. Gevorderde prestatiewerk is aftrekken, en daarom wordt het zelden gedaan: er valt niets te installeren.

De toets die zegt waar u staat: open de traagste pagina van uw site, niet uw startpagina. Dat is degene die uw ontevreden klanten hebben gezien.

Verder: het optimaliseren van de Core Web Vitals, de Core Web Vitals van WooCommerce en onze vergelijking tegenover WP Rocket. Qua gereedschap: paginaprestaties en beeldoptimalisatie — premiumversies met volledige terugbetaling binnen 14 dagen.