Planlægning af dataLayer-events for at optimere INP

Løsning af INP-udfordringer forårsaget af Google Tag Manager-eksekvering

For en af vores kunder observerede vi en 100ms reduktion i deres Interaction to Next Paint (INP)-metrik ved blot at omplanlægge, hvornår dataLayer.push()-funktionen eksekveres efter en brugerinteraktion. Denne forbedring blev opnået ved hjælp af en let anvendelig og testbar JavaScript "drop-in"-erstatning, der prioriterer gengivelse.

INP-problemet med dataLayer.push() 

Hvis du har arbejdet med Google Tag Manager (GTM), kender du dataLayer.push(). Det er standardmetoden til at sende data eller events til Data Layer, som gør det muligt for tags at udløses. Det er bredt anvendt, dybt integreret i mange sitefunktionaliteter, og dets ydeevnepåvirkninger bliver sjældent stillet spørgsmål ved. Dog kan det være problematisk at antage, at det altid eksekveres på det optimale tidspunkt for user experience.

Når dataLayer.push() kaldes direkte i en event handler for en brugerinteraktion (f.eks. et knapklik), eksekveres det typisk synkront. Det betyder, at alle GTM-tags konfigureret til at udløses baseret på den event, også vil forsøge at eksekvere øjeblikkeligt og blokere hovedtråden før en layoutopdatering. Denne blokering forhindrer browseren i hurtigt at gengive de visuelle ændringer, der forventes af brugerens interaktion (f.eks. åbning af en menu, visning af en loading-spinner), hvilket fører til en dårlig INP-score.

Lad os undersøge, hvad der sker. Performance-tracet nedenfor, fra en stor nyhedswebsite, fremhæver GTM-relateret aktivitet efter en brugerinteraktion. I dette tilfælde tog GTM-opgaverne cirka 90ms at eksekvere, og med en samlet INP-værdi på 263ms fejler denne interaktion denne Core Web Vitals!

Løsningen: prioritér paint, og push derefter til datalayeret!

Løsningen er både enkel og elegant og stemmer overens med INP-optimerings best practices: prioritér brugerens opfattelse af hastighed. I stedet for at eksekvere al kode (interaktionshåndtering, visuelle opdateringer og GTM-tracking) synkront, bør vi:

1. Eksekvere den kritiske kode for den visuelle opdatering øjeblikkeligt.
2. Tillade browseren at tegne disse visuelle ændringer.
3. Derefter eksekvere mindre kritisk kode, som at pushe events til dataLayer.

Denne tilgang kaldes ofte "yielding to the main thread." Lad os se virkningen, når vi anvender dette yielding-mønster på dataLayer.push()-kald på det samme site og for den nøjagtig samme interaktion som før. Den eneste forskel er, at vi har planlagt dataLayer.push() til at ske efter, at browseren har haft mulighed for at gengive det næste frame ved hjælp af requestAnimationFrame.

Som du kan se, består den samme interaktion, der tidligere fejlede, nu komfortabelt Core Web Vitals. Alle de nødvendige data sendes stadig til dataLayer. Den afgørende forskel er, at GTM-relaterede scripts nu eksekveres efter, at browseren har opdateret layoutet som svar på brugerens handling. Det betyder, at din besøgende får øjeblikkeligt visuelt feedback, hvilket forbedrer deres oplevelse, i stedet for at vente på, at tracking-scripts behandles.

Anvendelse af koden

Koden fungerer ved at overskrive standard dataLayer.push()-funktionen med en modificeret funktion, der pusher dataen til dataLayer, efter at en layoutopdatering er udført.

Await Paint hjælpefunktion

Denne hjælpefunktion bruger requestAnimationFrame til at planlægge et callback, der kører, efter at browseren har tegnet det næste frame.

// --- INP Yield Pattern Implementation ---

// This helper ensures that a function only runs after the next paint (or safe fallback)
async function awaitPaint(fn) {
    await new Promise((resolve) => {
        // Fallback timeout: ensures we don't hang forever if RAF never fires
        setTimeout(resolve, 200); 

        // Request the next animation frame (signals readiness to paint)
        requestAnimationFrame(() => {
            // Small delay to ensure the frame is actually painted, not just queued
            setTimeout(resolve, 50);
        });
    });

    // Once the paint (or fallback) happens, run the provided function
    if (typeof fn === 'function') {
        fn();
    }
}

Implementeringseksempel

Dette er et eksempel på en React utility-funktion, der automatisk planlægger dataLayer-pushet.

export const pushToDataLayer = (event: string, data: Record<string, any> = {}): void => {
  // Ensure dataLayer exists
  if (typeof window !== 'undefined') {
    window.dataLayer = window.dataLayer || [];
    
    // wait for paint
    awaitPaint(() => {
        // Push event and data to dataLayer
        window.dataLayer.push({
          event,
          ...data,
          timestamp: new Date().toISOString()
        });
    });
  }
};

// Usage in a React component:
// import { useState, useEffect } from 'react';
// import { pushToDataLayer } from '../utils/analytics';

// function ProductCard({ product }) {
//   const [isWishlisted, setIsWishlisted] = useState(false);
  
//   // Track wishlist changes
//   useEffect(() => {
//     if (isWishlisted) {
//       pushToDataLayer('addToWishlist', {
//         productId: product.id,
//         productName: product.name,
//         productPrice: product.price
//       });
//     }
//   }, [isWishlisted, product]);
  
//   return (
//     <div className="product-card">
//       <h3>{product.name}</h3>
//       <p>${product.price}</p>
//       <button onClick={() => setIsWishlisted(!isWishlisted)}>
//         {isWishlisted ? '♥' : '♡'} {isWishlisted ? 'Wishlisted' : 'Add to Wishlist'}
//       </button>
//     </div>
//   );
// }

Nem test: Global overskrivning

For hurtigt at teste dette mønster på tværs af hele dit site eller for eksisterende dataLayer.push()-implementeringer uden at refaktorere hver enkelt, kan du globalt overskrive dataLayer.push()-funktionen.

Vigtigt: Placér dette script højt i <head> af din HTML, umiddelbart efter at GTM container-scriptet er indlæst. Dette sikrer, at din overskrivning er på plads så hurtigt som muligt.

<script type="module">
    // Ensure dataLayer exists (standard GTM snippet part)
    window.dataLayer = window.dataLayer || [];

    // --- INP Yield Pattern Helper ---
    async function awaitPaint(fn) {
        return new Promise((resolve) => {
            const fallbackTimeout = setTimeout(() => {
                if (typeof fn === 'function') { fn(); }
                resolve();
            }, 200);
            requestAnimationFrame(() => {
                setTimeout(() => {
                    clearTimeout(fallbackTimeout);
                    if (typeof fn === 'function') { fn(); }
                    resolve();
                }, 50);
            });
        });
    }

    // --- Applying the pattern to Google Tag Manager dataLayer.push globally ---
    if (window.dataLayer && typeof window.dataLayer.push === 'function') {
        // Preserve the original push function
        const originalDataLayerPush = window.dataLayer.push.bind(window.dataLayer);

        // Override dataLayer.push
        window.dataLayer.push = function (...args) {
            // Using an IIFE to use async/await syntax if preferred,
            // or directly call awaitPaint.
            (async () => {
                await awaitPaint(() => {
                    // Call the original push with its arguments after yielding to paint
                    originalDataLayerPush(...args);
                });
            })();
            // Return the value the original push would have, if any (though typically undefined)
            // For GTM, the push method doesn't have a meaningful return value for the caller.
            // The primary purpose is the side effect of adding to the queue.
        };
        console.log('dataLayer.push has been overridden to improve INP.');
    }
</script>

Hvorfor dette hjælper Interaction to Next Paint

INP måler latensen fra en brugerinteraktion (f.eks. klik, tryk, tastetryk) til browseren tegner den næste visuelle opdatering som svar på den interaktion. Hvis du synkront eksekverer ressourcekrævende opgaver, som GTM event-behandling og tag-udløsning, umiddelbart efter en interaktion, blokerer du browserens hovedtråd. Dette forhindrer gengivelse af det visuelle feedback, brugeren forventer. Ved at udskyde ikke-kritisk JavaScript-eksekvering som GTM-tracking til efter, at browseren har tegnet de visuelle opdateringer, sikrer dette mønster, at brugerne modtager hurtigt visuelt feedback, hvilket markant forbedrer INP-scoren.

Hvorfor ikke bare bruge en fast forsinkelse, idle callback eller scheduler?

• Fast setTimeout(delay): At bruge en hardkodet forsinkelse (f.eks. setTimeout(..., 100)) er i bund og grund at gætte på, hvornår gengivelsen er færdig. Det er ikke adaptivt; det kan være for langt (unødvendig forsinkelse af tracking) eller for kort (blokerer stadig paint).
• requestIdleCallback: Denne API planlægger arbejde, når browseren er inaktiv. Selvom den er nyttig til baggrundsopgaver, garanterer den ikke eksekvering umiddelbart efter en specifik interaktions visuelle opdatering. Callbacket kan køre meget senere eller, i travle perioder, slet ikke før brugeren navigerer væk.
• Generiske schedulers (postTask osv.): Selvom browserens postTask-scheduler tilbyder prioritering, er requestAnimationFrame specifikt knyttet til gengivelseslivscyklussen. awaitPaint-hjælperen udnytter dette ved at bruge requestAnimationFrame som et signal om, at browseren forbereder sig på at tegne, og tilføjer derefter en minimal forsinkelse for at udløse efter, at tegningen sandsynligvis er færdig.

Afvejninger

Enhver optimering har potentielle afvejninger.

• Mikro-forsinkelse i dataindsamling: Denne teknik introducerer en forudsigelig mikro-forsinkelse (ca. 50-250ms, afhængigt af browserbelastning og de specifikke timeouts brugt i awaitPaint), før eventdata når Google Tag Manager.
• Risiko for datatab ved hurtig lukning: Hvis en besøgende udløser en event og derefter forlader siden inden for dette mikro-forsinkelsesvindue (før den udskudte dataLayer.push eksekveres), sendes den specifikke eventdata muligvis ikke. For kritiske events, hvor denne risiko er uacceptabel (f.eks. umiddelbart før en omdirigering eller side-unload), kan alternative tracking-mekanismer som navigator.sendBeacon overvejes for disse specifikke events, selvom dette er uden for omfanget af dataLayer.push-overskrivningen.

For de fleste standard analyse- og marketing-tracking er denne lille forsinkelse ubetydelig og en værdifuld afvejning for den markante forbedring af brugeropfattet ydeevne og INP-scorer. Dog er denne tilgang muligvis ikke egnet til scenarier med ultralav latens (f.eks. visse typer af real-time bidding-interaktioner direkte knyttet til GTM-events, eller meget følsomme finansielle dashboards, hvor millisekundpræcision i eventlogning er altafgørende).

Ellers opvejer gevinsten i INP-ydeevne og user experience typisk langt den minimale dataindsamlingslatens.Ellers opvejer gevinsten i INP-ydeevne og user experience typisk langt den minimale dataindsamlingslatens.