INP optimieren: 6 Methoden für bessere Web-Performance

• INP (Interaction to Next Paint) ist seit März 2024 offizieller Core Web Vital und ersetzt First Input Delay (FID) als wichtigste Responsiveness-Metrik
• Gute INP-Werte liegen bei 200 Millisekunden oder weniger, während Werte über 500ms als schlecht eingestuft werden
• JavaScript-Optimierung durch das Aufteilen langer Tasks ist der wichtigste Ansatz zur INP-Verbesserung
• DOM-Größe reduzieren auf unter 1.400 Nodes verbessert die Rendering-Performance erheblich
• Web Workers nutzen für schwere Berechnungen entlastet den Main Thread und verbessert die Interaktivität
• Debouncing und Throttling von Event-Callbacks reduziert die Anzahl ausgeführter Funktionen bei häufigen Benutzerinteraktionen
• Input Delay minimieren durch Vermeidung von Long Tasks während des Page Loads sorgt für sofortige Responsiveness
• Professionelle Mess-Tools wie Chrome DevTools, PageSpeed Insights und Web Vitals Extension ermöglichen präzise Analyse und Optimierung

Einführung in INP-Optimierung

Interaction to Next Paint (INP) hat die Landschaft der Web-Performance grundlegend verändert. Seit März 2024 ist diese Metrik ein offizieller Core Web Vital und hat First Input Delay (FID) als entscheidenden Responsiveness-Indikator abgelöst [1]. Anders als FID, das nur die erste Benutzerinteraktion misst, bewertet INP die gesamte Responsiveness einer Webseite durch Beobachtung aller qualifizierenden Interaktionen während des gesamten Besuchs eines Nutzers.

Die Bedeutung von INP für die Suchmaschinenoptimierung und Benutzererfahrung kann nicht überschätzt werden. Google verwendet diese Metrik als direkten Ranking-Faktor, was bedeutet, dass schlechte INP-Werte zu SEO-Problemen und verringerter Sichtbarkeit in den Suchergebnissen führen können [2]. Gleichzeitig beeinflusst eine langsame Interaktionsgeschwindigkeit direkt die Conversion-Rate und Nutzerzufriedenheit, da moderne Webnutzer eine sofortige Reaktion auf ihre Aktionen erwarten.

Was ist INP und warum ist es wichtig?

• INP misst die Latenz aller Click-, Tap- und Keyboard-Interaktionen während eines Seitenbesuchs
• Der finale INP-Wert entspricht der längsten beobachteten Interaktion (gelegentlich unter Ausschluss von Ausreißern)
• Gute INP-Werte liegen bei 200ms oder weniger, gemessen am 75. Perzentil der Seitenladezeiten
• INP ersetzt FID als Core Web Vital und bietet eine umfassendere Bewertung der Seitenresponsiveness

Interaction to Next Paint funktioniert als ganzheitliche Messgröße für die Benutzerinteraktions-Responsiveness. Im Gegensatz zu seinem Vorgänger FID, der ausschließlich die erste Eingabeverzögerung erfasste, sammelt INP Daten über alle Interaktionen während einer Session [3]. Diese umfassende Herangehensweise macht INP zu einem deutlich aussagekräftigeren Indikator für die tatsächliche Nutzererfahrung.

Die INP-Schwellenwerte sind klar definiert: Werte zwischen 0-200 Millisekunden gelten als gut, 200-500ms benötigen Verbesserung und Werte über 500ms werden als schlecht eingestuft [4]. Um sicherzustellen, dass diese Ziele für die Mehrheit der Nutzer erreicht werden, empfiehlt Google die Messung am 75. Perzentil der Seitenladezeiten, aufgeteilt nach mobilen und Desktop-Geräten.

Die drei Hauptkomponenten der Interaktionslatenz - Input Delay, Processing Duration und Presentation Delay - bilden zusammen die Gesamtlatenz einer Interaktion [5]. Jede dieser Komponenten trägt zur Gesamtzeit bei, weshalb eine ganzheitliche Optimierungsstrategie erforderlich ist, die alle Aspekte der Interaktionskette berücksichtigt.

Methode 1: JavaScript-Tasks optimieren und Long Tasks vermeiden

• Long Tasks (>50ms) blockieren den Main Thread und verzögern Benutzerinteraktionen erheblich
• Das Aufteilen großer JavaScript-Tasks in kleinere Chunks verbessert die Responsiveness
• setTimeout() und requestIdleCallback() ermöglichen strategisches Yielding an den Main Thread
• Async/defer-Attribute für nicht-kritische Scripts reduzieren Blocking während des Page Loads

Die Optimierung von JavaScript-Tasks stellt die wichtigste Methode zur INP-Verbesserung dar. Long Tasks, definiert als Aufgaben die länger als 50 Millisekunden dauern, blockieren den Main Thread und verhindern, dass der Browser auf Benutzerinteraktionen reagieren kann [6]. Diese Blockierung führt direkt zu erhöhten INP-Werten und einer verschlechterten Nutzererfahrung.

Task-Splitting-Strategien bieten einen effektiven Ansatz zur Lösung dieses Problems. Durch die Aufteilung großer JavaScript-Operationen in kleinere, verdauliche Chunks kann der Main Thread regelmäßig yielden und anderen Aufgaben Raum geben. Ein praktischer Ansatz nutzt setTimeout() mit einem Delay von 0 Millisekunden, um Arbeit in separate Tasks zu verschieben:

function processLargeDataset(data) {
  const batchSize = 100;
  let index = 0;

  function processBatch() {
    const endIndex = Math.min(index + batchSize, data.length);

    // Verarbeite aktuellen Batch
    for (let i = index; i < endIndex; i++) {
      processItem(data[i]);
    }

    index = endIndex;

    // Yield to main thread wenn mehr Arbeit vorhanden
    if (index < data.length) {
      setTimeout(processBatch, 0);
    }
  }

  processBatch();
}

RequestIdleCallback() bietet eine noch raffiniertere Lösung, indem es dem Browser erlaubt, schwere Berechnungen nur dann auszuführen, wenn der Main Thread idle ist [7]. Diese API ist besonders nützlich für nicht-zeitkritische Aufgaben wie Analytics-Verarbeitung oder Daten-Vorverarbeitung.

Das strategische Platzieren von async/defer-Attributen bei Script-Tags reduziert zusätzlich die Blocking-Zeit während des initialen Page Loads. Während async Scripts parallel zum HTML-Parsing lädt aber sofort ausführt, verschiebt defer die Ausführung bis nach dem vollständigen DOM-Aufbau [8].

Methode 2: Input Delay durch Main Thread Management reduzieren

• Input Delay entsteht durch Main Thread-Aktivitäten während der Interaktion
• Script-Evaluation und -Kompilierung während des Page Loads können Input Delays verursachen
• Kleinere JavaScript-Bundles reduzieren Parse- und Kompilierungszeiten
• Vermeidung von wiederkehrenden Timers (setInterval) minimiert Main Thread-Interference

Input Delay repräsentiert die Zeit zwischen der Initiierung einer Benutzerinteraktion und dem Beginn der Ausführung der entsprechenden Event-Callbacks. Diese Verzögerung entsteht primär durch andere Aktivitäten auf dem Main Thread, wie Script-Loading, Parsing, Kompilierung oder andere Interaktionen [9].

Ein kritischer Aspekt der Interaktivität während des Page Loads liegt in der Script-Evaluation. Nach dem Laden einer JavaScript-Datei aus dem Netzwerk muss der Browser diese noch parsen, in Bytecode kompilieren und schließlich ausführen. Abhängig von der Script-Größe kann diese Arbeit Long Tasks auf dem Main Thread verursachen, die wiederum Benutzerinteraktionen verzögern [10].

Script-Bundle-Optimierung durch das Aufteilen großer JavaScript-Dateien in kleinere, modulare Chunks reduziert diese Problematik erheblich. Modern bundling tools wie Webpack oder Vite bieten Code-Splitting-Features, die automatisch optimale Bundle-Größen erstellen:

// Dynamisches Importing für bessere Performance
const loadFeature = async () => {
  const { heavyFeature } = await import('./heavy-feature.js');
  return heavyFeature;
};

Timer-Management spielt eine weitere wichtige Rolle bei der Input Delay-Reduktion. setTimeout() und besonders setInterval() können mit Benutzerinteraktionen interferieren, wenn sie während der Interaktion ausgeführt werden. Die Evaluierung der Timer-Notwendigkeit und Reduzierung ihrer Arbeitslast minimiert potentielle Konflikte [11].

Zusätzlich trägt das Vermeiden von Interaction Overlap zur Input Delay-Reduktion bei. Dies tritt auf, wenn Nutzer eine weitere Interaktion initiieren, bevor die vorherige abgeschlossen ist. Debouncing-Techniken für Eingabefelder und die Nutzung von AbortController für ausstehende Fetch-Requests helfen, den Main Thread zu entlasten [12].

Methode 3: Event Callbacks und Processing Time optimieren

• Event Callbacks sollten nur rendering-kritische Arbeit vor dem nächsten Frame ausführen
• Nicht-kritische Operationen können mit requestAnimationFrame() und setTimeout() verzögert werden
• Yielding-Strategien ermöglichen es dem Browser, UI-Updates schneller zu rendern
• Entfernung unnötiger Event-Callbacks reduziert die Processing Time erheblich

Die Optimierung der Event Callbacks stellt die zweite Phase der Interaktionslatenz dar und beeinflusst direkt die Processing Duration. Der Schlüssel liegt darin, nur die notwendigste Arbeit in Event Callbacks auszuführen, die für das nächste Frame erforderlich ist, während alle anderen Operationen verzögert werden.

Strategisches Yielding nach UI-Updates ermöglicht dem Browser, Rendering-Arbeit sofort zu beginnen, anstatt auf die Vollendung aller Callback-Operationen zu warten. Ein praktisches Beispiel aus einem Rich-Text-Editor verdeutlicht diese Technik:

textBox.addEventListener('input', (inputEvent) => {
  // Sofortiges UI-Update für nächstes Frame
  updateTextBox(inputEvent);

  // Verzögerung aller anderen Arbeiten
  requestAnimationFrame(() => {
    setTimeout(() => {
      const text = textBox.textContent;
      updateWordCount(text);
      checkSpelling(text);
      saveChanges(text);
    }, 0);
  });
});

Diese Technik reduziert die Processing Duration erheblich, da nur die rendering-kritischen Updates vor dem nächsten Frame ausgeführt werden [13]. Die Kombination aus requestAnimationFrame() und setTimeout() stellt sicher, dass Hintergrundaufgaben erst nach dem nächsten Paint ausgeführt werden.

Callback-Evaluation sollte als erster Optimierungsschritt erfolgen. Viele Event Callbacks enthalten überflüssige Operationen, die entweder komplett entfernt oder zeitlich verschoben werden können. Die Identifikation render-kritischer vs. nicht-kritischer Arbeit bildet die Grundlage für effektive Optimierung.

Layout Thrashing vermeiden stellt einen weiteren wichtigen Aspekt dar. Synchrone Layout-Berechnungen, die durch das Lesen von Style-Properties unmittelbar nach deren Änderung entstehen, können erhebliche Performance-Einbußen verursachen [14]. Die Verwendung von FastDOM oder ähnlichen Bibliotheken hilft, DOM-Operationen zu batchen und Layout Thrashing zu vermeiden.

Methode 4: DOM-Größe reduzieren und Rendering optimieren

• Große DOM-Strukturen (>1.400 Nodes) verlangsamen sowohl initiales Rendering als auch Interaktions-Updates
• Content-visibility CSS-Property ermöglicht lazy Rendering von Off-Screen-Elementen
• DOM-Flattening und additive Ansätze reduzieren die initiale DOM-Komplexität
• Vermeidung von display:none für versteckte Inhalte spart DOM-Nodes

DOM-Größen-Optimierung beeinflusst sowohl das initiale Rendering als auch die Performance von Interaktions-Updates. Laut Lighthouse gilt eine DOM-Größe als exzessiv, wenn sie 1.400 Nodes überschreitet [15]. Große DOMs benötigen nicht nur mehr Zeit für das initiale Rendering, sondern auch für Updates als Reaktion auf Benutzerinteraktionen.

Content-Visibility bietet eine moderne CSS-Lösung für das Lazy Rendering von Off-Screen-Elementen. Diese Property ermöglicht es dem Browser, das Rendering von Elementen zu überspringen, die außerhalb des Viewports liegen:

.content-section {
  content-visibility: auto;
  contain-intrinsic-size: 500px; /* Geschätzte Höhe für Layout-Stabilität */
}

Die Nutzung von content-visibility: auto kann die Rendering-Zeit sowohl beim Page Load als auch bei Benutzerinteraktionen erheblich reduzieren, da der Browser weniger Layout- und Paint-Arbeit durchführen muss [16].

DOM-Struktur-Optimierung durch verschiedene Strategien trägt zur Größenreduktion bei. Das Flattening von verschachtelten Strukturen reduziert die DOM-Tiefe, während additive Ansätze - das Hinzufügen von DOM-Elementen erst bei Bedarf - die initiale DOM-Größe klein halten [17].

Problematische Praktiken wie das Kopieren/Einfügen von formatiertem Text in WYSIWYG-Editoren, die Verwendung von Page Builders mit aufgeblähtem HTML oder das Verstecken von Inhalten mit display: none statt deren kompletter Entfernung sollten vermieden werden [18]. JavaScript-basierte DOM-Generierung sollte ebenfalls minimiert werden, da sie zusätzliche Processing-Zeit erfordert und das automatische Browser-Chunking verhindert.

Methode 5: Web Workers für schwere Berechnungen nutzen

• Web Workers ermöglichen die Ausführung von JavaScript-Code parallel zum Main Thread
• Schwere Berechnungen und Datenverarbeitung können vollständig vom Main Thread ausgelagert werden
• Message-Passing zwischen Main Thread und Worker ermöglicht effiziente Kommunikation
• Service Workers können für wiederkehrende Background-Tasks genutzt werden

Web Workers stellen eine leistungsstarke Lösung dar, um schwere JavaScript-Operationen vom Main Thread zu entkoppeln und somit die Interaktions-Responsiveness zu verbessern. Diese Background-Threads können komplexe Berechnungen durchführen, ohne die Benutzeroberfläche zu blockieren [19].

Worker-Implementation für typische Use Cases wie Datenverarbeitung oder komplexe Algorithmen zeigt deutliche INP-Verbesserungen:

// main.js
const worker = new Worker('heavy-computation.js');

function processData(largeDataset) {
  return new Promise((resolve) => {
    worker.postMessage(largeDataset);

    worker.onmessage = (event) => {
      resolve(event.data);
    };
  });
}

// heavy-computation.js
self.onmessage = function(event) {
  const data = event.data;
  const result = performComplexCalculation(data);
  self.postMessage(result);
};

Message-Passing-Optimierung zwischen Main Thread und Worker sollte effizient gestaltet werden. Transferable Objects für große ArrayBuffers reduzieren Kopieroverhead, während Batch-Processing von Messages die Kommunikations-Latenz minimiert [20].

Service Workers bieten zusätzliche Möglichkeiten für Background-Processing, besonders für wiederkehrende Tasks wie Daten-Synchronisation oder Cache-Management. Diese persistenten Workers können auch dann arbeiten, wenn die Hauptseite nicht aktiv ist, was die Performance bei der nächsten Sitzung verbessert [21].

Worker-Grenzen müssen beachtet werden: DOM-Manipulation ist nicht möglich, und die Kommunikation erfolgt ausschließlich über Messages. Dennoch überwiegen die Vorteile bei CPU-intensiven Operationen wie Bildverarbeitung, mathematischen Berechnungen oder großen Datenset-Transformationen deutlich.

Methode 6: Debouncing und Event-Optimierung implementieren

• Debouncing reduziert die Häufigkeit von Event-Callback-Ausführungen bei schnellen Interaktionen
• Throttling begrenzt die Ausführungsrate von Events auf ein vernünftiges Maß
• RequestAnimationFrame-basierte Event-Optimierung synchronisiert Updates mit Browser-Rendering
• AbortController ermöglicht das Abbrechen ausstehender Operationen bei neuen Interaktionen

Debouncing und Throttling stellen essenzielle Techniken zur Optimierung von Event-Callbacks dar, besonders bei häufigen Benutzerinteraktionen wie Tippen oder Scrollen. Diese Methoden reduzieren die Anzahl der Funktionsausführungen und damit die Main Thread-Belastung [22].

Debouncing-Implementation verzögert die Ausführung einer Funktion bis nach einer bestimmten Ruheperiode:

function debounce(func, delay) {
  let timeoutId;
  return function (...args) {
    clearTimeout(timeoutId);
    timeoutId = setTimeout(() => func.apply(this, args), delay);
  };
}

// Verwendung für Sucheingaben
const searchInput = document.getElementById('search');
const debouncedSearch = debounce(performSearch, 300);
searchInput.addEventListener('input', debouncedSearch);

Throttling begrenzt die Ausführungsrate auf ein bestimmtes Intervall, was besonders bei Scroll- oder Resize-Events nützlich ist:

function throttle(func, limit) {
  let inThrottle;
  return function (...args) {
    if (!inThrottle) {
      func.apply(this, args);
      inThrottle = true;
      setTimeout(() => inThrottle = false, limit);
    }
  };
}

RequestAnimationFrame-basierte Optimierung synchronisiert Event-Callbacks mit dem Browser-Rendering-Zyklus und vermeidet unnötige Updates zwischen Frames [23]:

let rafId;
function optimizedScrollHandler() {
  if (rafId) return;

  rafId = requestAnimationFrame(() => {
    handleScroll();
    rafId = null;
  });
}

window.addEventListener('scroll', optimizedScrollHandler);

AbortController für ausstehende Operationen verhindert, dass veraltete Requests den Main Thread belasten, wenn neue Interaktionen auftreten:

let controller;

async function handleUserInput(query) {
  // Vorherige Requests abbrechen
  if (controller) {
    controller.abort();
  }

  controller = new AbortController();

  try {
    const response = await fetch(`/api/search?q=${query}`, {
      signal: controller.signal
    });
    // Verarbeite Response
  } catch (error) {
    if (error.name !== 'AbortError') {
      console.error('Search failed:', error);
    }
  }
}

INP messen und monitoren

• Field Data durch Real User Monitoring (RUM) bietet die genauesten INP-Werte
• PageSpeed Insights und Chrome UX Report (CrUX) liefern aggregierte Performance-Daten
• Chrome DevTools Performance Panel ermöglicht detaillierte Interaktions-Analyse
• Web Vitals Chrome Extension bietet einfache Echtzeit-Messungen

Field Data-Sammlung bildet die Grundlage für effektive INP-Optimierung. Real User Monitoring (RUM) liefert die wertvollsten Insights, da es tatsächliche Nutzererfahrungen widerspiegelt statt synthetischer Tests [24]. Die web-vitals JavaScript Library ermöglicht das präzise Erfassen von INP-Daten:

import { onINP } from 'web-vitals';

onINP((metric) => {
  // INP-Daten an Analytics senden
  console.log('INP:', metric.value);
  console.log('Element:', metric.attribution.interactionTarget);
  console.log('Event type:', metric.attribution.interactionType);
});

Lab Data-Tools ergänzen Field Data für detaillierte Diagnosen. Chrome DevTools Performance Panel bietet umfassende Interaktions-Analyse durch Timeline-Recording während Benutzerinteraktionen. Das Lighthouse Timespan-Feature ermöglicht INP-Messungen für spezifische Interaktionssequenzen [25].

PageSpeed Insights und der Chrome UX Report (CrUX) liefern aggregierte Performance-Daten für Millionen von Websites, einschließlich INP-Werte am 75. Perzentil [26]. Diese Tools bieten wervolle Benchmarking-Möglichkeiten und Trend-Analyse über Zeit.

Web Vitals Chrome Extension stellt die einfachste Methode für Echtzeit-INP-Monitoring dar. Mit aktivierter Console-Logging-Option liefert sie detaillierte diagnostische Informationen für jede Interaktion, einschließlich Input Delay, Processing Time und Presentation Delay [27].

Tools und Ressourcen für INP-Optimierung

• Google PageSpeed Insights bietet INP-Analyse und konkrete Optimierungsvorschläge
• Chrome DevTools ermöglicht detaillierte Performance-Profiling für Interaktionen
• Web-vitals Library stellt präzise INP-Messung und -Reporting bereit
• Lighthouse Timespans Mode analysiert spezifische Interaktionssequenzen

Google PageSpeed Insights fungiert als primäres Tool für INP-Assessment und bietet sowohl Field- als auch Lab-Data. Die Plattform zeigt nicht nur aktuelle INP-Werte, sondern auch spezifische Optimierungsempfehlungen basierend auf der Seitenanalyse [28]. Die Integration mit Chrome UX Report liefert zusätzlich historische Daten für Trend-Analyse.

Chrome DevTools Performance Panel ermöglicht granulare Interaktions-Analyse durch detaillierte Timeline-Aufzeichnungen. Red Bars in der Activity Summary markieren Long Tasks, während die Flame Graph-Visualisierung bottlenecks in Event Callbacks identifiziert [29]. Das User Timing API kann für Custom Performance Marks genutzt werden:

// Custom Performance Markierung
performance.mark('interaction-start');
handleUserInteraction();
performance.mark('interaction-end');
performance.measure('interaction-duration', 'interaction-start', 'interaction-end');

Web-vitals JavaScript Library bietet die offizielle Implementierung für INP-Messungen und ermöglicht detailliertes Performance-Monitoring [30]. Die Library unterstützt Custom-Attribution für spezifische Interaktionstypen und Element-Selektoren.

Lighthouse Timespans Mode stellt eine weniger intimidierenden Alternative zum DevTools Performance Panel dar und fokussiert auf spezifische Interaktionssequenzen. Das Tool bietet automatische INP-Bewertung und aufgeschlüsselte Latenz-Komponenten für einfache Problemidentifikation [31].

Häufige INP-Probleme und Lösungsansätze

• Client-side Rendering verursacht Non-Chunked HTML-Processing und Long Tasks
• Drittanbieter-Scripts können Main Thread-Blocking verursachen
• Übermäßige DOM-Manipulation führt zu Layout Thrashing
• Unoptimierte Event-Listener verursachen Performance-Bottlenecks

Client-side Rendering Probleme entstehen hauptsächlich durch die fehlende automatische Chunking-Optimierung des Browsers. Während Server-side Rendering HTML in Chunks streamt und dem Browser erlaubt, zwischen Parsing-Phasen zu yielden, erstellt Single Page Application (SPA)-Pattern große HTML-Strukturen in einem einzigen Task [32].

Lösungsstrategien für SPA-Performance umfassen Incremental Rendering, Virtual DOM Optimierung und Streaming Server-Side Rendering (SSR). React's Concurrent Features und Vue 3's Fragment-Support bieten Built-in-Optimierungen für bessere INP-Performance.

Drittanbieter-Script-Management erfordert strategische Herangehensweise. Resource Hints wie preconnect und dns-prefetch reduzieren Netzwerk-Latenz, während Script-Prioritäten durch loading="lazy" oder dynamisches Laden optimiert werden können [33]:

// Lazy Loading für Drittanbieter-Scripts
const loadThirdPartyScript = () => {
  if ('IntersectionObserver' in window) {
    const observer = new IntersectionObserver((entries) => {
      entries.forEach(entry => {
        if (entry.isIntersecting) {
          loadScript('/third-party-script.js');
          observer.disconnect();
        }
      });
    });
    observer.observe(targetElement);
  }
};

Layout Thrashing Vermeidung durch Batch-DOM-Updates und die Nutzung von transform statt Layout-Properties für Animationen verbessert die Rendering-Performance erheblich [34]. CSS contain-Property hilft zusätzlich, Layout-Recalculations zu isolieren.

Zukunft von INP und Web Performance

• INP wird voraussichtlich weitere Verfeinerungen in der Messmethodik erhalten
• Browser-APIs für bessere Performance-Kontrolle sind in Entwicklung
• Machine Learning-basierte Performance-Optimierung gewinnt an Bedeutung
• Core Web Vitals werden kontinuierlich an moderne Web-Technologien angepasst

Die Evolution von INP als Core Web Vital zeigt Googles Commitment zur kontinuierlichen Verbesserung der Web-Performance-Metriken. Zukünftige Entwicklungen könnten verfeinerte Messalgorithmen, bessere Outlier-Detection und erweiterte Attribution-Features umfassen [35].

Emerging Browser-APIs wie die Long Task API, Element Timing API und Layout Instability API bieten Entwicklern zunehmend granulare Kontrolle über Performance-Monitoring und -Optimierung. Diese APIs ermöglichen proaktive Performance-Überwachung statt reaktiver Problemlösung.

Machine Learning-Integration in Performance-Tools wird voraussichtlich automatische Optimierungsvorschläge und Predictive Performance Analysis ermöglichen. Tools wie Lighthouse CI und Speedlify zeigen bereits Ansätze für kontinuierliche Performance-Regression-Detection.

Die Konvergenz von Performance und User Experience wird weiterhin die Entwicklung neuer Metriken und Optimierungsstrategien vorantreiben. Progressive Web Apps (PWAs), WebAssembly und Edge Computing schaffen neue Möglichkeiten für Performance-Optimierung bei gleichzeitig neuen Herausforderungen für Responsiveness-Messung [36].

Quellen

[1] https://developers.google.com/search/blog/2023/05/introducing-inp
[2] https://web.dev/articles/inp
[3] https://www.onely.com/blog/difference-between-fid-and-inp/
[4] https://nitropack.io/blog/post/improve-interaction-to-next-paint-inp
[5] https://web.dev/articles/optimize-inp
[6] https://web.dev/articles/optimize-long-tasks
[7] https://developer.mozilla.org/en-US/docs/Web/API/Window/requestIdleCallback
[8] https://web.dev/articles/efficiently-load-third-party-javascript
[9] https://web.dev/articles/optimize-inp#identify-and-reduce-input-delay
[10] https://web.dev/articles/optimize-inp#the-relationship-between-script-evaluation-and-long-tasks
[11] https://coralogix.com/guides/real-user-monitoring/interaction-to-next-paint-inp-5-ways-optimize/
[12] https://web.dev/articles/optimize-inp#avoid-interaction-overlap
[13] https://web.dev/articles/optimize-inp#yield-to-allow-rendering-work-to-occur-sooner
[14] https://web.dev/articles/avoid-large-complex-layouts-and-layout-thrashing
[15] https://developer.chrome.com/en/docs/lighthouse