INP Presentation Delay: DOM-storlek, layoutarbete och renderingsoptimering

Interaction to Next Paint (INP)-problem orsakade av presentation delay

Den här sidan är en del av vår serie om Interaction to Next Paint (INP). INP mäter den totala tiden från en användarinteraktion till nästa visuella uppdatering. Presentation delay är den tredje och sista fasen av INP, efter input delay och processing time. Om du är ny på INP, läs vår guide om hur du identifierar och åtgärdar INP-problem först.

I den här artikeln fokuserar vi på presentation delay: vad som orsakar det, hur det påverkar Interaction to Next Paint och hur du optimerar det för att förbättra dina INP-resultat.

Kort sagt: Interaction to Next Paint (INP) mäter hur lång tid det tar för en användare att se en visuell förändring på en sida efter att ha interagerat med den. Detta INP kan delas upp i 3 komponenter: "input delay", "processing time" och "presentation delay."

Presentation delay är den största bidragaren till det totala INP-värdet och står för ungefär 42 % av den totala INP-tiden i genomsnitt. Det innebär att optimering av din renderingspipeline och förenkling av din HTML-struktur kan ha en betydande inverkan på din webbplats INP-poäng.

Presentation Delay: Har du någonsin klickat på en knapp och undrat varför det tog en bråkdels sekund för länge att se resultatet? Det är Interaction to Next Paint (INP) i praktiken. Presentation delay är det sista steget i interaktionsprocessen, som startar efter att ditt klick har bearbetats men innan du ser några visuella förändringar.

Förstå presentation delay

Presentation är den sista fasen av en interaktion. Presentation delay representerar den tid det tar för webbläsaren att rendera visuella uppdateringar som följer efter interaktionen. Presentation delay börjar när händelsehanterarna för interaktionen har körts klart och slutar när nästa bildruta (som innehåller de visuella ändringarna) har målats. Presentation delay kan påverkas av olika faktorer, inklusive layoutens komplexitet, DOM-storleken och mängden renderingsarbete som krävs.

Interaction to Next Paint (INP) kan delas upp i 3 delmoment: "Input Delay", "Processing Time" och "Presentation Delay".

Presentation delay och INP

Presentation delay är den sista fasen av INP. I genomsnitt utgör presentation delay cirka 42 % av den totala INP-tiden, vilket gör det till den enskilt största bidragaren till långsamma interaktioner.

Hos CoreDash samlar vi in miljontals Core Web Vitals-datapunkter varje timme. Baserat på dessa data står presentation delay för 42 % av Interaction to Next Paint. Det är mer än processing time (40 %) och avsevärt mer än input delay (18 %). Trots att den är den största bidragaren är presentation delay ofta den svåraste fasen att optimera eftersom den involverar webbläsarens renderingspipeline snarare än din applikationskod.

Exempel på presentation delay: Tänk dig att du sitter med mobilen och surfar på en e-handelswebbplats för att hitta ett par nya skor. Du trycker på en produktbild för att se mer detaljer. Men din telefon är lite äldre och har svårt att hänga med. Du trycker på bilden (interaktion). Telefonen behöver lite tid för att bearbeta förfrågan och uppdatera skärmen (Processing Time). Webbplatsen behöver rendera den nya sidan med den större bilden och detaljerna. Slutligen tar det en märkbar tid innan de nya produktdetaljerna och bilden visas på din skärm (Presentation Delay). Denna fördröjning i INP kan vara frustrerande för användare och det är därför det är viktigt att åtgärda den.

Vad orsakar hög presentation delay?

Presentation delay omfattar allt arbete webbläsaren utför efter att dina händelsehanterare har körts klart och innan pixlarna visas på skärmen. Det inkluderar omberäkning av stilar, layoutberäkning, målning och compositing. Flera faktorer bidrar till hög presentation delay:

Stor DOM-storlek

En stor eller djupt nästlad DOM är en av de vanligaste orsakerna till hög presentation delay. Varje gång webbläsaren behöver uppdatera sidans visuella tillstånd efter en interaktion måste den omberäkna stilar, beräkna layout och måla om de berörda elementen. Kostnaden för vart och ett av dessa steg ökar med antalet DOM-noder som påverkas.

Google rekommenderar att du håller din DOM under 1 400 element, med ett maximalt djup på 32 nivåer och högst 60 barn per föräldranod. När din DOM överskrider dessa tröskelvärden lägger webbläsaren betydligt mer tid på omberäkning av stilar och layoutberäkning efter varje interaktion.

Tänk dig följande scenario: en användare klickar på en knapp som växlar en CSS-klass på ett containerelement. Om det containern har 5 000 underordnade noder måste webbläsaren potentiellt omberäkna stilar för alla, även om bara ett fåtal element faktiskt ändras visuellt. Denna omberäkning av stilar sker synkront före nästa målning, vilket direkt ökar presentation delay.

För specifika tekniker för att minska din DOM, läs vår guide om att åtgärda överdriven DOM-storlek.

Överdrivet layoutarbete

Layout (även kallat "reflow") är processen där webbläsaren beräknar position och dimensioner för varje synligt element på sidan. Efter en interaktion som modifierar DOM eller ändrar CSS-egenskaper som påverkar geometri (width, height, margin, padding, top, left) måste webbläsaren utföra layout innan den kan måla den uppdaterade bildrutan.

Två mönster är särskilt skadliga för presentation delay:

Forcerad synkron layout uppstår när JavaScript läser en layoutegenskap (som offsetHeight eller getBoundingClientRect()) efter att ha gjort en DOM-ändring som ogiltigförklarar layouten. Webbläsaren tvingas utföra layout synkront, inom din händelsehanterare, för att returnera ett korrekt värde. Detta layoutarbete blir då en del av processing time, men eventuell efterföljande layout som utlöses av ytterligare DOM-ändringar blir en del av presentation delay.

Layout thrashing är det upprepade mönstret att skriva till DOM och sedan läsa layoutegenskaper i en loop. Varje läsning tvingar webbläsaren att omberäkna layouten, och varje skrivning ogiltigförklarar layouten igen. Detta kan orsaka dussintals eller till och med hundratals onödiga layoutberäkningar per interaktion. Här är ett exempel på layout thrashing och hur du åtgärdar det:

// BAD: Layout thrashing inside a loop
function resizeItems() {
  const items = document.querySelectorAll('.item');
  items.forEach(item => {
    // Read (forces layout)
    const parentWidth = item.parentElement.offsetWidth;
    // Write (invalidates layout)
    item.style.width = parentWidth + 'px';
  });
}

// GOOD: Batch reads, then batch writes
function resizeItems() {
  const items = document.querySelectorAll('.item');
  // Read all values first
  const widths = Array.from(items).map(
    item => item.parentElement.offsetWidth
  );
  // Then write all values
  items.forEach((item, i) => {
    item.style.width = widths[i] + 'px';
  });
}

Rendering på klientsidan i Single Page Applications

Rendering av HTML på klientsidan kan avsevärt påverka presentation delay, särskilt i Single Page Applications (SPA:er). När en användarinteraktion utlöser en ruttändring eller en stor UI-uppdatering måste SPA-ramverket:

1. Köra virtual DOM-diffningsalgoritmen för att avgöra vad som ändrats
2. Applicera de resulterande DOM-mutationerna på den verkliga DOM
3. Utlösa omberäkning av stilar och layout för alla berörda element
4. Måla den uppdaterade bildrutan

I React-applikationer är virtual DOM-avstämningsprocessen en del av processing time, men de resulterande DOM-mutationerna och deras renderingskostnad faller under presentation delay. Ju fler DOM-noder ditt komponentträd producerar, desto dyrare blir avstämningen och det efterföljande renderingsarbetet.

För att mildra detta i React- och Next.js-applikationer:

• Använd React.memo() för att förhindra onödiga omrenderingar av barnkomponenter som tar emot samma props.
• Använd useDeferredValue() för värden som utlöser dyra omrenderingar, så att React kan prioritera mer brådskande uppdateringar.
• Håll komponentträd grunda. Djupt nästlade komponenthierarkier producerar djupt nästlad DOM, vilket ökar kostnaden för både avstämning och webbläsarens rendering.
• Använd virtualiseringsbibliotek (som react-window eller @tanstack/react-virtual) för långa listor så att DOM bara innehåller de synliga objekten.

Minska presentation delay

Nu när vi förstår orsakerna, här är de mest effektiva strategierna för att minimera presentation delay.

Minimera DOM-storleken

Den mest effektfulla optimeringen för presentation delay är att hålla din DOM liten. Här är praktiska tekniker:

• Ta bort oanvända HTML-element, särskilt djupt nästlade wrapper-divar.
• Använd listvirtualisering för långa listor (rendera bara synliga objekt plus en liten buffert).
• Platta till djupt nästlade strukturer där det är möjligt.
• Använd CSS Grid och Flexbox istället för nästlade divar för layout.

// Virtualize long lists to reduce DOM size
// Before: 10,000 items in the DOM
<ul>
  {allItems.map(item => <li key={item.id}>{item.name}</li>)}
</ul>

// After: only visible items in the DOM (using react-window)
import { FixedSizeList } from 'react-window';

<FixedSizeList
  height={600}
  itemCount={allItems.length}
  itemSize={50}
  width="100%"
>
  {({ index, style }) => (
    <div style={style}>{allItems[index].name}</div>
  )}
</FixedSizeList>

Använd content-visibility för att lazy-rendera innehåll utanför skärmen

CSS-egenskapen content-visibility talar om för webbläsaren att hoppa över rendering av innehåll utanför skärmen tills användaren scrollar nära det. Detta minskar mängden renderingsarbete under interaktioner genom att begränsa omfånget av omberäkning av stilar och layout till den synliga delen av sidan.

/* Apply content-visibility to sections below the fold */
.below-fold-section {
  content-visibility: auto;
  contain-intrinsic-size: auto 500px;
}

/* Apply to individual items in long lists */
.list-item {
  content-visibility: auto;
  contain-intrinsic-size: auto 80px;
}

Egenskapen contain-intrinsic-size anger en uppskattad höjd så att webbläsaren kan beräkna scrolllistans storlek korrekt utan att rendera innehållet. Detta förhindrar layoutförskjutningar när användaren scrollar och innehållet blir synligt.

För fler CSS-optimeringsstrategier som minskar renderingskostnaden, se vår guide om att ta bort oanvänd CSS.

Minimera layoutarbete som utlöses av interaktioner

När du designar interaktioner, föredra CSS-egenskaper som inte utlöser layout. Egenskaper som transform och opacity kan hanteras av GPU-compositorn utan att utlösa layout eller målning. Istället för att animera top, left, width eller height, använd transform: translate() och transform: scale().

Använd CSS-egenskapen will-change för att ge webbläsaren en ledtråd om att ett element kommer att animeras. Detta gör att webbläsaren kan skapa ett separat compositorlager för elementet och isolera dess rendering från resten av sidan:

/* Promote elements to their own compositor layer */
.animated-element {
  will-change: transform, opacity;
}

/* Toggle visibility with opacity instead of display */
.modal {
  opacity: 0;
  pointer-events: none;
  transform: translateY(10px);
  transition: opacity 0.2s, transform 0.2s;
}

.modal.active {
  opacity: 1;
  pointer-events: auto;
  transform: translateY(0);
}

Identifiera långa presentation delays

För att identifiera långa presentation delays kan du använda Chromes prestandaprofilerare. Öppna DevTools (Ctrl+Shift+I), navigera till fliken Performance, tryck på inspelning och interagera med sidan.

Du kan sedan analysera tidslinjen för en interaktion och visualisera de olika faserna, inklusive presentation delay. Genom att granska renderingsuppdateringarna som sker efter att händelsehanterarna har körts klart kan du identifiera eventuella flaskhalsar som bidrar till en lång presentation delay. Leta efter stora poster för "Recalculate Style", "Layout" och "Paint" i tidslinjen. Dessa representerar det arbete webbläsaren utför under presentation delay-fasen.

Identifiera presentation delay med RUM-data

Mäta presentation delay med Long Animation Frames (LoAF)

Long Animation Frames (LoAF) API ger detaljerade insikter i orsakerna till renderingsfördröjningar, inklusive de som uppstår under användar- interaktioner. API:et tillhandahåller tidsdata som hjälper dig att separera processing time från presentation delay och identifiera vilka skript som bidrar till renderingsflaskhalsar.

De viktigaste LoAF-egenskaperna för att förstå presentation delay är:

• renderStart: när webbläsaren påbörjade renderingsfasen (omberäkning av stilar, layout, målning)
• styleAndLayoutStart: när beräkning av stilar och layout påbörjades
• duration: total varaktighet för den långa animationsramen
• blockingDuration: hur mycket av ramen som blockerades av skript

Skillnaden mellan slutet av skriptkörningen och slutet av ramen representerar den rena renderingskostnaden, vilket är presentation delay. Så här kan du observera och logga dessa data:

// Measure presentation delay using LoAF API
const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.duration > 50) {
      const scriptEnd = Math.max(
        ...entry.scripts.map(s => s.startTime + s.duration)
      );
      const presentationDelay = (
        entry.startTime + entry.duration
      ) - Math.max(scriptEnd, entry.renderStart);

      console.log('Presentation delay breakdown:', {
        totalDuration: entry.duration,
        renderStart: entry.renderStart,
        styleAndLayoutStart: entry.styleAndLayoutStart,
        estimatedPresentationDelay: presentationDelay,
        scriptCount: entry.scripts.length
      });
    }
  }
});

observer.observe({
  type: 'long-animation-frame',
  buffered: true
});

RUM-verktyg som CoreDash integrerar LoAF-data och ger ytterligare insikter i långa animationsramar, såsom skriptattribueringsdata. Dessa verktyg hjälper dig förstå vilka skript och DOM-ändringar som bidrar till renderingsfördröjningar så att du kan optimera din kodbas för bättre responsivitet.

Utforska de andra INP-faserna

Presentation delay är bara en del av Interaction to Next Paint. För att fullt ut optimera dina INP-resultat bör du även åtgärda de andra två faserna:

• Input Delay: Minimera väntetiden innan händelsehanterare börjar köras. Input delay står för ungefär 18 % av den totala INP-tiden.
• Processing Time: Optimera händelsehanterarens körning som står för ungefär 40 % av den totala INP-tiden.

För ett komplett diagnostiskt arbetsflöde, se vår guide om hur du hittar och åtgärdar INP-problem. För ytterligare renderingsoptimeringsstrategier, utforska våra guider om att åtgärda överdriven DOM-storlek och ta bort oanvänd CSS. Gå tillbaka till INP-hubbsidan för den fullständiga översikten.