Speed Auditor: Find ud af, hvad der holder din WordPress tilbage

Nogle WordPress-webstedsadministratorer er besat af PageSpeed Insights eller GTmetrix. Mit råd, og det fra mange andre, der ved meget mere om det, er, at du ikke skal give disse målinger mere betydning, end de har.

Hvis den opfattede indlæsningshastighed er god, er det ikke nødvendigt at sætte alt "i grønt". I mange tilfælde er det endda kontraproduktivt, fordi man kan forfalde til overoptimering, eller endnu værre, man kan ende med at ødelægge forskellige ting i forsøget på at fikse én ting.

Men uanset om du er WPO-aficionado, optimeringsentusiast eller bare vil forsøge at forbedre din hjemmesides reaktionsevne, er disse værktøjer næsten uundværlige. Problemet er, at de tilbyder "stillbilleder" taget fra eksterne servere. Men hvad sker der, når du som administrator surfer rundt på dit site, hvad med de annoncer, der indlæses sent, eller den menu, der springer, lige når du skal til at klikke?

Oprindelse

Speed Auditor blev født som et svar på et personligt behov for at have flere enkle, men kraftfulde lokale diagnosticeringsværktøjer. Det er ikke et optimeringsplugin (det ændrer ikke noget i din kode), det er et revisionsplugin i realtid.

Hvis du leder efter et godt, muligvis det bedste, betalte plugin til WPO, som du kan bruge til at foretage ændringer og finjusteringer, kan du se på Perfmatters. Hvis du derimod er på udkig efter noget gratis og enkelt, hvor du ikke bliver forvirret over indstillinger og justeringer, men hvor der er mange muligheder, kan du prøve WPO Rocket Tweaks af Fernando Tellado, som findes i WordPress repository.

Hvis du ikke ved, hvad en DOM-node eller en latenstidsmåling er, skal du ikke bekymre dig. Speed Auditor er designet til at hjælpe dig med at forstå din hjemmeside på et øjeblik:

• Den smarte indikator: Et ikon, der skifter farve, vises i din administratorlinje. Hvis det er grønt, er din LCP (den tid, det tager at se de vigtigste ting) optimal. Hvis det bliver orange eller rødt, er der noget, der kræver din opmærksomhed.

• Auditér, mens du surfer: Du behøver ikke at konfigurere noget kompliceret. Du aktiverer pluginet, og mens du tjekker dine indlæg, arbejder det i baggrunden med at analysere, om dine billeder er for tunge, eller om din server reagerer langsomt.
• Mere menneskelige rapporter: Med et enkelt klik kan du downloade en .txt-fil, som du kan sende til din udvikler eller gemme for at sammenligne resultater efter ændringer.

Under motorhjelmen

Version 1.1.8 forsøger at give en vis dybde i diagnostikken for at spare tid på at rode i browserkonsollen.

• Præcis LCP-identifikation: Plugin'et registrerer nøjagtigt, hvilket element (billede eller tekstblok) der udløste Largest Contentful Paint.
• DOM dybdeanalyse: Afgørende for at undgå "DOM size excessive". Speed Auditor opdeler antallet af noder efter zoner (Header, Content, Footer) og advarer dig, hvis indlejringen overstiger 15-20 niveauer.
• Media Latency Monitor: Måler den faktiske overførselstid (Resource Timing API) for billeder. Hvis det tager 500 ms at downloade et billede, markerer plugin'et det som kritisk.
• Ingen påvirkning af serveren: Al behandling sker på klientsiden (browseren). Der er ingen tunge databaseforespørgsler eller PHP-processer, der gør webstedet langsommere.

Det store spring. Kommer snart: Speed Auditor 1.1.9 (med "Radar CLS")

Indtil nu har Cumulative Layout Shift (CLS) været et abstrakt tal i en rapport. Man vidste, at noget bevægede sig, men man vidste ikke altid hvad. Meget snart, i version 1.1.9, vil dette ændre sig.

Radar- eller Visual CLS "Highlighter"-knappen skal indføres.

Forestil dig, at du aktiverer en "radar"-tilstand, der tegner røde bokse over ethvert element, der bevæger sig, mens du scroller. Dette, som nogle udvidelser allerede gør med mere eller mindre succes, er altid en meget nyttig visuel hjælp til at forsøge at fange de "overløb", der nogle gange undslipper øjet.

• Er det et AdSense-banner, der skubber til dit indhold? Du kan se det med en rød boks. Du kan gå dybere ind i dette problem her.
• Er det et billede uden definerede dimensioner? Radaren vil fange det.
• Total vedholdenhed: Du vil kunne gennemse hele dit website med radaren tændt; plugin'et vil huske, at du ønsker at fortsætte med at kontrollere hvert hjørne visuelt.

Denne opdatering vil også indeholde en kort teknisk ordliste, som vil blive udvidet til at omfatte tips og vejledninger, som vil blive integreret i dit WordPress-dashboard, så udtryk som ins, iframe eller figure ikke længere er et mysterium.

Ideen er at forbedre både analysens respons og de rapporter, der genereres, efterhånden som jeg tester den i forskellige scenarier, og hvis jeg modtager forslag til forbedringer eller advarsler om fejl.

Version 1.1.8 er nu tilgængelig til at rydde op i dine metrics, og snart vil 1.1.9 gøre det endnu nemmere at rette op på den visuelle stabilitet i WordPress. Hvis du installerer den nu, vil du modtage opdateringen inden for kort tid.

Hvordan fungerer det?

Koden følger disse tre trin:

1. Performance-observatøren

Browseren (Chrome, Edge, Opera) har en indbygget API kaldet Performance API. Plugin'et registrerer en "watcher" kaldet PerformanceObserver, der er specifikt konfigureret til layout-shift-inputtypen.

Hver gang noget bevæger sig på skærmen, efter at det først er blevet malet, genererer browseren en hændelse. Plugin'et opfanger denne begivenhed og udtrækker to vigtige data:

• Værdien af forskydningen: (Dette tal er 0,0145).
• Det skyldige element: Browseren fortæller plugin'et præcis, hvilken HTML-node der blev flyttet.

2. Filteret "Seneste interaktion"

Det er her, plugin'et forsøger at være smart. Ikke alle bevægelser er "dårlige". Hvis du klikker på en rullemenu, og indholdet ruller ned, er det en forventet bevægelse fra brugerens side.

Plugin'et tjekker en egenskab, der hedder hadRecentInput. Hvis du har trykket på en tast eller klikket inden for de sidste 500 ms, markerer browseren denne bevægelse som "forventet", og plugin'et ignorerer den for at undgå falske positiver. Det registrerer kun bevægelser, der opstår uventet (som f.eks. en annonce, der pludselig dukker op).

3. Visuel gengivelse (de røde bokse)

Når plugin'et har det element, der er blevet flyttet, kommer den visuelle del i spil:

1. Beregning af koordinater: Bruger en funktion kaldet getBoundingClientRect() til at finde ud af, hvor elementet er på skærmen i det præcise øjeblik (pixel op, pixel til venstre).
2. Indsprøjtning af ramme: Opret en div med absolut position, en 2px rød kant og et meget højt z-index for at tegne oven på alt.
3. Etiketten: Tilføj en lille boks øverst til venstre i den røde boks med navnet på etiketten (ins, img, div) og værdien af den akkumulerede CLS.

Hvorfor er det bedre end en ekstern rapport?

Værktøjer som PageSpeed opdager nogle gange ikke CLS, fordi de ikke scroller til bunden eller ikke venter på, at visse annoncer indlæses.

Ved at bruge persistens måler plugin'et CLS akkumuleret gennem den faktiske brugers browsersession. Hvis et element bevæger sig lidt i starten og lidt, når man scroller, lægger plugin'et det sammen og fremhæver det, hvilket giver dig det mest omtrentlige reelle tal, som Google ender med at se i sin"Chrome User Experience"-rapport (CrUX).