Optimera JavaScript-prioritet för snabbare sidladdningar
Lär dig hur du prioriterar skript effektivt för att förbättra Core Web Vitals.
Hantera JavaScript-prioriteringar för bättre webbprestanda
En sak har alltid varit tydlig: inte all JavaScript är skapad lika. Vissa skript hanterar kritiska interaktioner som 'menyinteraktion' eller 'lägg i varukorgen' medan andra skript är mycket mindre viktiga. Ta till exempel ditt 'exit intent'-popupskript som bjuder in besökare som är på väg att lämna din webbplats att fylla i ett frågeformulär. Jag är säker på att vi alla skulle kunna leva utan de sista, men det skulle vara riktigt svårt att navigera en webbplats utan de första.
Ändå, på 'din genomsnittliga webbplats' på en teknisk nivå görs denna distinktion nästan aldrig. All JavaScript 'läggs bara till' på sidan och webbläsaren får lista ut det själv. Det är ett problem eftersom din webbläsare inte har någon aning om vad som är viktigt och vad som inte är det. Vi, som utvecklare, har det. Så låt oss fixa det!
Hur JavaScript-prioritet kan påverka Core Web Vitals
Att bara lägga till skript på sidan utan rätt övervägande kan påverka alla 3 Core Web Vitals. Largest Contentful Paint, Interaction to Next Paint och Cumulative Layout Shift.
Exempel: LCP-nätverksresursen fördröjs av renderingsblockerande JavaScript
Largest Contentful Paint är känslig för bandbredds- och CPU-konkurrens. När för många skript tävlar om tidiga nätverksresurser fördröjer det Largest Contentful Paint-nätverksresursen och tidigt CPU-arbete fördröjer LCP genom att blockera huvudtråden.
Interaction to Next Paint kan påverkas av skript som körs precis före en interaktion. När skript körs blockerar de huvudtråden och fördröjer alla interaktioner under den exekveringstiden.
Skript kan också orsaka en Cumulative Layout Shift om skript 'ändrar hur sidan ser ut'. Annonsskript som injicerar banners på sidan och sliders är ökända för att göra detta.
5 typer av JavaScript-prioriteringar
Jag gillar att skilja mellan 5 typer av JavaScript-prioriteringar. Låt oss snabbt diskutera dessa innan vi gräver djupare.
- Render Critical: dessa skript är bland de värsta att ha. De ändrar sidans layout och utan att ladda dessa skript kommer layouten att vara helt annorlunda. Exempel: vissa slider-skript eller ett A/B-test.
- Critical Scripts: Dessa skript hanterar kritisk sidfunktionalitet och utan dessa skript är kritiska uppgifter som att lägga till en produkt i varukorgen, webbplatssökning eller navigering inte möjliga.
- Important scripts. Dessa skript hanterar viktig (affärs)logik och din webbplats är beroende av dessa. Till exempel: Analytics
- Nice to have scripts. Dessa skript är bra att ha men om det verkligen gäller behöver vi dem inte för att sidan ska fungera. Till exempel en chattwidget eller ett exit intent
- Future Scripts. Dessa skript kan vara kritiska eller bra att ha men vi behöver dem inte just nu eftersom 'andra steg' behöver tas innan vi faktiskt kan använda dessa skript. Till exempel ett flerstegs-utcheckningsskript.
1. Render-Critical Scripts
Dessa är de mest störande skripten, eftersom de direkt påverkar hur sidan visas. Utan dem kan layouten brytas eller se drastiskt annorlunda ut från sin avsedda design. Exempel inkluderar skript för sliders eller A/B-testramverk som ändrar layouten tidigt i laddningsprocessen.
Problemet med dessa typer av skript är att de inte kan skjutas upp eller fördröjas. Varje fördröjning kommer att orsaka att webbplatsens layout skiftar, vilket orsakar dålig UX och att Core Web Vitals misslyckas.
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<title>Page Title</title>
<link href="styles.css" rel="stylesheet" />
<script src="render-critical.js"></script>
</head>
<body></body>
</html>
Bästa praxis:
- Undvik render critical-skript som dessa när det är möjligt. Skriv om din kod för att undvika beroende av dessa typer av skript.
- Om det inte går att undvika, infoga inline eller ladda bara de absolut nödvändiga delarna av dessa skript.
- Skjut inte upp eller asynkronisera dessa skript och placera dem högst upp i head för att trigga en 'så tidig som möjligt'-nedladdning.
2. Critical Scripts
Dessa skript möjliggör grundläggande interaktioner. Utan dem blir kritiska uppgifter som webbplatsnavigering, att lägga till varor i varukorgen, cookie-meddelande eller att utföra en sökning omöjliga. De är oumbärliga för webbplatsens kärnfunktionalitet.
Dessa skript bör placeras i head på sidan med antingen async- eller defer-attributet.
<script defer src="critical.js"></script> <script async src="critical.js"></script>
Bästa praxis:
- Håll skript som dessa till ett minimum och kombinera inte denna funktionalitet med annan, mindre kritisk funktionalitet.
- Ladda dessa skript tidigt med
asyncellerdefer, beroende på deras beroenden. - Använd Real User Monitoring (RUM)-verktyg, som Coredash, för att identifiera flaskhalsar i exekveringen och säkerställa att deras prestanda överensstämmer med användarnas behov.
3. Important Scripts
Även om de inte är direkt kopplade till webbplatsens användbarhet, stödjer viktiga skript viktiga affärsfunktioner. Analysskript ger till exempel viktig data men behöver inte laddas före viktigare visuella element. Uppenbarligen kan skillnaden mellan kritiska och viktiga skript vara en fråga om debatt, så se till att diskutera med alla intressenter innan du sätter denna prioritet!
Det finns 3 sätt att sänka skriptprioriteten för dessa typer av skript.
<html>
<head>
<!-- method 1: low fetchpriority -->
<script fetchpriority="low" defer src="important.js"></script>
<!-- method 2: inject after DOMContentLoaded -->
<script>
document.addEventListener('DOMContentLoaded', function() {
var script = document.createElement('script');
script.src = 'important.js';
document.body.appendChild(script);
});
</script>
</head>
<body>
<!-- method 3: place at the bottom of the page -->
<script defer src="important.js"></script>
</body>
</html>
1. Låg fetchpriority.
Att ställa in fetchpriority sänker den relativa prioriteten för skriptet. Andra uppskjutna eller asynkroniserade skript kommer troligen att köas med hög prioritet medan skripten med fetchprioriy="low" kommer att köas med låg prioritet. Beroende på din sida (eller din renderingsväg) kan detta vara tillräckligt för att prioritera andra resurser som din Largest Contentful Paint-bild och viktiga typsnitt.
2: Injicera efter DOMContentLoaded
Genom att injicera skriptet efter DOMContentLoaded-eventet säkerställer du att skriptet börjar laddas ner direkt efter att HTML har tolkats fullständigt. Detta tillåter upptäckbara resurser, som bilder och typsnitt, att ta företräde. Denna metod ger en balans: skriptet börjar laddas tillräckligt tidigt för att undvika fördröjningar i funktionalitet men konkurrerar inte med tidiga resurser som är avgörande för den initiala sidvisningen.
3: placera längst ner på sidan
Denna klassiska teknik skjuter upp skriptladdning tills efter att webbläsaren har bearbetat hela dokumentet och uppnår ungefär samma resultat som föregående teknik. Den enda skillnaden är att teknik 2 hoppar över din webbläsares preload scanner medan denna teknik inte gör det. Preload scanner är en lättviktig snabbskanner som din webbläsare använder för att snabbt identifiera och köa kritiska resurser. Att hoppa över preload scanner kan vara en bra idé om det finns en möjlighet att lazy-laddade bilder finns i viewporten medan att använda preload scanner kommer att snabba upp laddningen för detta skript.
4. Nice-to-Have Scripts
Dessa skript förbättrar user experience men krävs inte för att webbplatsen ska fungera. Exempel inkluderar chattwidgets, kundfeedback-popups eller valfria animationer. Även om de är fördelaktiga bör de inte störa den primära user experience.
Dessa skript är en idealisk kandidat att ladda med ett mönster som kallas 'lazy on load'. Detta innebär att vänta på sidans load-event och sedan, under ledig tid, injicera skriptet. Att vänta på load-eventet säkerställer att skriptet inte konkurrerar om bandbredd och CPU med viktigare tidiga resurser. Att vänta på ett ledigt ögonblick säkerställer att webbläsaren inte hanterar viktigare uppgifter som användarinput.
Här är ett fungerande exempel:
window.addEventListener("load", () => {
window.requestIdleCallback(() => {
const script = document.createElement("script");
script.src = "/path/to/script.js";
document.head.appendChild(script);
});
});Bästa praxis:
- Lazy-ladda dessa skript efter att sidan har laddats och vänta på ett ledigt ögonblick.
- Förstå att skript som laddas med detta mönster inte garanteras att laddas snabbt
5. Future Scripts
Future scripts är de som inte behövs förrän specifika villkor är uppfyllda. Till exempel blir ett flerstegs-utcheckningsskript relevant först efter att en användare har lagt till varor i sin varukorg. Dessa skript kan ofta vänta till mycket senare i användarens resa.
Ta en titt på detta exempel. Det använder intersection observer för att ladda JS-logiken som krävs för registreringsskriptet först när formuläret är i den synliga viewporten.
<!DOCTYPE html>
<html>
<head>
<script>
document.addEventListener("DOMContentLoaded", function () {
const form = document.querySelector("form");
const observer = new IntersectionObserver(function (entries) {
entries.forEach((entry) => {
if (entry.isIntersecting) {
const script = document.createElement("script");
script.src = "/sign-up.js";
document.head.appendChild(script);
observer.unobserve(form);
}
});
});
observer.observe(form);
});
</script>
</head>
<body>
<form action="/sign-up" method="post">
<label for="email">Email:</label>
<input type="email" id="email" name="email" required />
<button type="submit">Sign Up</button>
</form>
</body>
</html>
Bästa praxis:
- Ladda dessa skript på begäran, utlösta av användaråtgärder.
- Använd code-splitting-tekniker för att leverera bara de delar som krävs vid varje steg.
- Injicera dem dynamiskt bara när det behövs, till exempel när en användare scrollar till en specifik sektion.
Secure your Q3 Metrics.
Do not let technical debt derail your Core Web Vitals. I provide the strategy, the code, and the verification to pass Google's assessment.
- Strategic Planning
- Code Implementation
- Verification & Testing
