Speed Auditor: ta reda på vad som hindrar din WordPress

Vissa WordPress-webbplatsadministratörer är besatta av PageSpeed Insights eller GTmetrix. Mitt råd, och det från många andra som vet mycket mer om det, är att du inte ska ge dessa mätvärden mer betydelse än de har.

Om den upplevda laddningshastigheten är bra är det inte nödvändigt att lägga allt "i grönt". I många fall är det till och med kontraproduktivt eftersom du kan överoptimera, eller ännu värre, förstöra olika saker för att försöka fixa en sak.

Men oavsett om du är en WPO-fantast, en optimeringsentusiast eller bara vill försöka förbättra din webbplats respons är dessa verktyg nästan oumbärliga. Problemet är att de erbjuder "stillbilder" som hämtas från externa servrar. Men vad händer när du som administratör surfar på din sajt, hur blir det med annonserna som laddas sent eller menyn som hoppar precis när du ska klicka?

Ursprung

Speed Auditor föddes som ett svar på ett personligt behov av att ha flera enkla men kraftfulla lokala diagnosverktyg. Det är inte ett optimeringsplugin (det ändrar ingenting i din kod), det är ett realtidsgranskningsplugin.

Om du letar efter ett bra, möjligen det bästa, betalda plugin-programmet för WPO, med vilket du kan göra ändringar och finjusteringar, ta en titt på Perfmatters. Om du å andra sidan letar efter något gratis och enkelt, utan att få huvudet i en vridning med inställningar och justeringar, men med många möjligheter, kan du prova WPO Rocket Tweaks av Fernando Tellado, tillgänglig i WordPress repository.

Om du inte vet vad en DOM-nod eller latensmätning är, oroa dig inte. Speed Auditor är utformad för att hjälpa dig att förstå din webbplats på ett överskådligt sätt:

• Den smarta indikatorn: En ikon som byter färg visas i adminfältet. Om den är grön är din LCP (den tid det tar att se de viktigaste sakerna) optimal. Om den blir orange eller röd är det något som kräver din uppmärksamhet.

• Granska medan du surfar: Du behöver inte konfigurera något komplicerat. Du aktiverar insticksprogrammet och medan du kontrollerar dina inlägg arbetar det i bakgrunden och analyserar om dina bilder är för tunga eller om din server svarar långsamt.
• Mer mänskliga rapporter: Med ett klick kan du ladda ner en .txt-fil som du kan skicka till din utvecklare eller spara för att jämföra resultat efter att du har gjort ändringar.

Under motorhuven

Version 1.1.8 försöker tillhandahålla en djupgående diagnostik för att spara tid i webbläsarkonsolen.

• Exakt LCP-identifiering: Plugin-programmet upptäcker exakt vilket element (bild eller textblock) som utlöste Largest Contentful Paint.
• DOM-djupanalys: Avgörande för att undvika "DOM-storlek överdriven". Speed Auditor bryter ner antalet noder per zon (Header, Content, Footer) och varnar dig om nestningen överstiger 15-20 nivåer.
• Övervakare för medielatens: Mäter den faktiska överföringstiden (Resource Timing API) för bilder. Om en bild tar 500 ms att ladda ner markerar plugin-programmet den som kritisk.
• Ingen påverkan på servern: All bearbetning sker på klientsidan (webbläsaren). Det finns inga tunga databasfrågor eller PHP-processer som saktar ner webbplatsen.

Det stora språnget. Kommer inom kort: Speed Auditor 1.1.9 (med "Radar CLS")

Fram till nu har Cumulative Layout Shift (CLS) varit en abstrakt siffra i en rapport. Du visste att något rörde sig, men du visste inte alltid vad. Mycket snart, i version 1.1.9, kommer detta att förändras.

"Highlighter"-knappen för radar eller Visual CLS ska införas.

Föreställ dig att du aktiverar ett "radar"-läge som ritar röda rutor över alla element som rör sig medan du scrollar. Detta, som vissa tillägg redan gör, med mer eller mindre framgång, är alltid ett mycket användbart visuellt hjälpmedel för att försöka fånga de "överflöden" som ibland undgår ögat.

• Är det en AdSense-banner som pushar ditt innehåll? Du kommer att se den med en röd ruta. Du kan gå djupare in i detta problem här.
• Är det en bild utan definierade dimensioner? Radarn kommer att fånga upp den.
• Total uthållighet: Du kommer att kunna surfa på hela din webbplats med radarn på; plugin-programmet kommer att komma ihåg att du vill fortsätta att visuellt granska varje hörn.

Denna uppdatering kommer också att innehålla en kort teknisk ordlista, som kommer att utökas med tips och handledning, som kommer att integreras i din WordPress instrumentpanel, så att termer som ins, iframe eller figure inte längre är ett mysterium.

Tanken är att förbättra både analysens svar och de rapporter som genereras när jag testar den i olika scenarier och om jag får några förslag till förbättringar eller varningar om fel.

Version 1.1.8 är nu tillgänglig för att städa upp dina mätvärden, och snart kommer 1.1.9 att göra det ännu enklare att fixa den visuella stabiliteten i WordPress. Om du installerar den nu kommer du att få uppdateringen inom kort.

Hur fungerar det?

Koden följer dessa tre steg:

1. Prestationsobservatören

Webbläsaren (Chrome, Edge, Opera) har ett inbyggt API som heter Performance API. Plugin-programmet registrerar en "watcher" som heter PerformanceObserver som är specifikt konfigurerad för inmatningstypen layout-shift.

Varje gång något rör sig på skärmen efter att det har målats initialt genererar webbläsaren en händelse. Plugin-programmet fångar upp den händelsen och extraherar två viktiga data:

• Värdet på förskjutningen: (Det talet är 0,0145).
• Det skyldiga elementet: Webbläsaren berättar för plugin-programmet exakt vilken HTML-nod som flyttades.

2. Filtret "Senaste interaktion"

Det är här plugin-programmet försöker vara smart. Inte alla rörelser är "dåliga". Om du klickar på en rullgardinsmeny och innehållet rullar ner, är det en förväntad rörelse av användaren.

Pluginet kontrollerar en egenskap som heter hadRecentInput. Om du har tryckt på en tangent eller klickat under de senaste 500 ms markerar webbläsaren den rörelsen som "förväntad" och plugin-programmet ignorerar den för att undvika falska positiva resultat. Det upptäcker endast rörelser som inträffar oväntat (t.ex. en annons som plötsligt visas).

3. Visuell rendering (de röda rutorna)

När plugin-programmet har det element som har flyttats kommer den visuella delen in i bilden:

1. Beräkning av koordinater: Använder en funktion som heter getBoundingClientRect() för att ta reda på var elementet befinner sig på skärmen i det exakta ögonblicket (pixel upp, pixel vänster).
2. Injektion av ram: Skapa en div med absolut position, en 2px röd kant och ett mycket högt z-index för att rita ovanpå allt.
3. Etiketten: Lägg till en liten ruta längst upp till vänster om den röda rutan med namnet på etiketten (ins, img, div) och värdet på den ackumulerade CLS:en.

Varför är detta bättre än en extern rapport?

Verktyg som PageSpeed misslyckas ibland med att upptäcka CLS eftersom de inte skrollar till botten eller inte väntar på att vissa annonser ska laddas.

Genom att använda persistens mäter insticksprogrammet CLS som ackumulerats under hela den faktiska användarens webbläsarsession. Om ett element rör sig lite i början och lite när du skrollar, lägger insticksprogrammet till det och markerar det, vilket ger dig den mest ungefärliga verkliga siffran som Google kommer att se i sin"Chrome User Experience" (CrUX)-rapport.