Webbprestanda, Behåll din Lightroom Scores 100.

Kvaliteten på webbplatsernas upplevelse är avgörande för att du ska kunna uppnå webbplatsens affärsmål och få besökarna nöjda.

Adobe Experience Manager (AEM) är optimerat för att leverera enastående upplevelser och optimala webbprestanda. Med Realanvändningsövervakning (RUM) datainsamling från operationer, information samlas in kontinuerligt från fältanvändning och erbjuder ett sätt att iterera på prestandamätningar för faktisk användning utan att behöva vänta på att CRuX-data ska visa effekterna av kod och förändringar i driftsättningen. Det är vanligt att fältdata som samlas in i RUM avviker från labbresultaten, eftersom nätverks-, geolokaliserings- och bearbetningskraften för riktiga enheter är mycket mer olika än de simulerade förhållandena i ett labb.

The Google PageSpeed Insight Service har visat sig vara ett utmärkt labbmätningsverktyg. Det kan användas för att undvika den långsamma försämringen av webbplatsens prestanda och upplevelsepoäng.

Om du startar projektet med mallen som i Självstudiekurs för utvecklare, får du en mycket stabil Lightroom-poäng på PageSpeed Insight för både Mobile och Desktop på 100. På varje komponent i fyr-poängen finns det en viss buffert som projektkoden kan förbruka och som fortfarande ligger inom gränserna för en perfekt 100 fyr.

Testa pull-begäranden

Det visar sig att det är svårt att förbättra poängen i Lighthund när det är lågt, men det är inte svårt att behålla det på 100 om du kontinuerligt testar.

När du öppnar en pull-begäran (PR) för ett projekt används test-URL:erna i beskrivningen av ditt projekt för att köra PageSpeed Insights-tjänsten mot. AEM GitHub-roboten misslyckas automatiskt med din PR om poängen är under 100 med lite buffert för att ta hänsyn till en viss volatilitet i resultaten.

Resultatet är för mobilens fyr eftersom de tenderar att vara svårare att åstadkomma än för datorer.

Varför Google PageSpeed Insights?

Många team och individer använder sina egna konfigurationer för att mäta poängen i Lighthuse. Olika team har utvecklat sina egna testresurser och använder sina egna testverktyg med konfigurationer som har konfigurerats som en del av deras kontinuerliga övervaknings- och resultatrapporteringsrutiner.

En webbplats prestanda påverkar dess rankning i sökresultat, vilket återspeglas i Core Web Vitals i crUX-rapporten. Google har en bra hantering av de relevanta genomsnittliga kombinationerna av enhetsinformation (t.ex. skärmstorlek) och nätverksprestanda för dessa enheter. Men i slutänden är SEO den ultimata skiljedomaren för vad bra jämfört med dålig webbprestanda är. Eftersom den specifika konfigurationen är ett rörligt mål, bör prestandspraxis anpassas till det aktuella genomsnittliga antalet enheter och nätverksegenskaper globalt.

I stället för att använda en projektspecifik konfiguration för Lightroom-testning använder vi de ständigt uppdaterade konfigurationerna som en del av de mobila och stationära strategier som de senaste versionerna av Google refererar till PageSpeed Insights API.

Även om det kan finnas ytterligare insikter om att vissa utvecklare känner att de kan samla in data från andra sätt att mäta poängen i Lighthuse, för att kunna föra en meningsfull och jämförbar prestandakonversation i olika projekt, måste det finnas ett sätt att mäta prestanda generellt. Standardtjänsten PageSpeed Insight är det mest auktoritativa och mest allmänt accepterade labbtestet när det gäller att mäta prestanda.

Det är dock viktigt att komma ihåg att de rekommendationer du får från PageSpeed Insights inte nödvändigtvis leder till bättre resultat, särskilt inte ju närmare du kommer till en fyndighetspoäng på 100.

Core Web Vitals (CWV) som samlats in av den inbyggda RUM-datainsamlingen spelar en viktig roll när det gäller att validera resultaten. För mindre förändringar innebär dock variationen i resultaten och bristen på tillräckliga datapunkter (trafik) under en kort tidsperiod att det är opraktiskt att få statistiskt relevanta resultat i de flesta fall.

Inläsning i tre faser (E-L-D)

Genom att dela upp nyttolasten på en webbsida i tre faser blir det relativt enkelt att uppnå en ren fyr-poäng och därför sätta en baslinje för en bra kundupplevelse.

Med inläsningsmetoden för tre faser delas sidans nyttolast och utförande upp i tre faser

Fas E: Sökare

I angelägen fas, allt som behöver läsas in för det sanna LCP som ska visas har lästs in. I ett projekt består detta vanligtvis av koden, CSS-formaten och JavaScript-filerna.

I många fall LCP -elementet finns i ett -block (skapas ofta genom automatisk blockering) där -blocket .js och .css måste också läsas in.

Blockinläsaren tar bort avsnitt stegvis, vilket innebär att alla block i det första avsnittet måste läsas in för LCP för att bli synliga. Därför kan det vara bra att ha ett mindre avsnitt som innehåller så lite som behövs högst upp på en sida.

Det är en bra tumregel att behålla den sammanlagda nyttolasten före LCP visas under 100 kB, vilket vanligtvis ger en LCP snabbare än 1 560 ms (LCP poängsättning vid 100 i PSI). I synnerhet på mobilen tenderar nätverket att vara bandbreddsbegränsat, så att inläsningssekvensen ändras före LCP har minimal eller ingen inverkan.

Läsa in från eller ansluta till en andra origo före LCP att det inte finns någon anledning att upprätta en andra anslutning (TLS, DNS osv.) lägger till en avsevärd fördröjning i LCP.

Fas L: Lazy

I lat den del av nyttolasten som inte påverkar den totala blockeringstiden (TBT) och slutligen den första indatafördröjningen (FID).

Detta inkluderar exempelvis inläsningsblock (JavaScript och CSS) samt inläsning av alla återstående bilder enligt deras loading="lazy" och andra JavaScript-bibliotek som inte blockerar. Den lata fasen är vanligtvis allt som händer i de olika blocks som du kommer att skapa för att tillgodose projektbehoven.

I denna fas skulle det fortfarande vara tillrådligt att huvuddelen av nyttolasten kommer från samma ursprung och kontrolleras av den första parten, så att ändringar kan göras vid behov för att undvika negativa effekter på TBT, TTI och FID.

Fas D: Fördröjd

I försenad de delar av nyttolasten som inte direkt påverkar upplevelsen och/eller inte kontrolleras av projektet och kommer från tredje part, Fundera på marknadsföringsverktyg, hantering av medgivande, utökad analys, chatt/interaktionsmoduler etc. som ofta används via tagghanteringslösningar.

Det är viktigt att förstå att för att effekten på den övergripande kundupplevelsen ska minimeras måste starten av den här fasen försenas avsevärt. Den fördröjda fasen bör vara minst tre sekunder efter LCP-händelsen för att ge tillräckligt med tid för resten av upplevelsen att klaras av.

Den fördröjda fasen hanteras vanligtvis i delayed.js som fungerar som en första catch-all för skript som orsakar TBT. Helst TBT problem tas bort från skripten i fråga antingen genom att de läses in utanför huvudtråden (i en webbarbetare) eller genom att den faktiska blockeringstiden tas bort från koden. När problemen är åtgärdade kan dessa bibliotek enkelt läggas till i den lata fasen och läsas in tidigare.

Helst finns det ingen blockeringstid i skripten, vilket ibland är svårt att uppnå så ofta använda tekniker som tagghanterare eller verktyg för att skapa stora JavaScript-filer som blockeras när webbläsaren tolkar dem. Från ett prestandaperspektiv är det tillrådligt att ta bort dessa tekniker, se till att dina enskilda skript inte blockerar och läsa in dem enskilt som separata mindre filer.

Sidhuvud och sidfot

Sidhuvudet och specifikt sidfoten finns inte i den kritiska sökvägen till sidan LCPoch därför läses de in asynkront i sina respektive block. I allmänhet bör resurser som inte har samma livscykel (vilket innebär att de uppdateras med redigeringsändringar vid olika tidpunkter) lagras i separata dokument för att göra cachelagringskedjan mellan originalen och webbläsaren enklare och effektivare. Genom att hålla dessa resurser åtskilda ökar cacheträffens frekvens och minskar komplexiteten i cacheminnet och cachehanteringen.

Typsnitt

Eftersom webbteckensnitt ofta är en ansträngning för bandbredd och läses in från ett annat ursprung via en teckensnittstjänst som https://fonts.adobe.com eller https://fonts.google.comär det i stort sett omöjligt att läsa in teckensnitt före LCPoch därför läggs de vanligtvis till i lazy-styles.css och läses in efter LCP visas.

LCP-block

Det finns situationer där den faktiska LCP -elementet ingår inte i koden som skickas till klienten. Detta inträffar när det finns en instruktion eller sökning (t.ex. en tjänst som anropas, ett fragment som är inläst eller en sökning som behöver utföras i en .json) för LCP -element.
I sådana fall är det viktigt att sidan som läses in väntar med att gissa LCP kandidatbild (för närvarande den första bilden på sidan) tills det första blocket har gjort de nödvändiga ändringarna i DOM.
Identifiera vilka block som ska väntar innan blockering för LCP load, du kan lägga till de block som innehåller LCP -element till LCP_BLOCKS array in scripts.js.

Bonus: hastigheten är grön

Att bygga webbplatser som är snabba, små och snabba att återge är inte bara en bra idé att leverera enastående upplevelser som konverterar bättre, utan också ett bra sätt att minska koldioxidutsläppen.