Wie die Verbesserung des INP von Fotocasa zu einem Anstieg der wichtigsten Messwerte um 27% beigetragen hat

Veröffentlicht am 14. Oktober 2025

Interaction to Next Paint (INP) ist ein wichtiger Core Web Vitals-Messwert zur Messung der Reaktionsschnelligkeit. Bei Fotocasa wurden in der Google Search Console eine beträchtliche Anzahl von Seiten als „Verbesserungsbedürftig“ und „Schlecht“ eingestuft, als INP 2024 den First Input Delay (FID) ersetzt hat. In dieser Fallstudie werden die Tools und Strategien beschrieben, die zur Diagnose und Behebung dieser Probleme eingesetzt wurden. Dadurch konnte der INP erheblich verbessert werden.

Wo das Fotocasa-Team angefangen hat

Vor der Umstellung von FID auf INP lag fast jede Seite sowohl auf Computern als auch auf Mobilgeräten innerhalb des Schwellenwerts „Gut“. Das bedeutet, dass alle Core Web Vitals zu diesem Zeitpunkt (LCP, CLS und FID) gut abgeschnitten haben. Nach der Umstellung auf INP wurden jedoch fast alle Seiten als „Verbesserungsbedürftig“ und einige sogar als „Schlecht“ eingestuft, da die INP-Werte für die meisten Nutzerinteraktionen durchgehend über 200 Millisekunden lagen.

Google Search Console mit der Verteilung der Fotocasa-URLs auf dem Desktop. Viele Seiten haben sich von „Gut“ zu „Muss verbessert werden“ verschoben, nachdem INP zu einem Core Web Vital wurde.
Abbildung 1. Google Search Console – Verteilung von Fotocasa-URLs auf dem Desktop: Wenn INP in Kraft tritt, werden viele URLs, die zuvor als „gut“ eingestuft wurden, in die Kategorie „Muss verbessert werden“ verschoben.

Durch diese Änderung wurde dem Fotocasa-Team klar, dass es einen wichtigen Aspekt der Nutzerfreundlichkeit übersehen hatte. Während bei FID nur die Verzögerung der ersten Interaktion gemessen wurde, wird bei INP die Reaktionszeit aller Interaktionen bewertet, wobei Verzögerungen bei der Eingabeverarbeitung und Darstellung berücksichtigt werden. Diese umfassendere Messung ist ein viel besserer Proxy für die tatsächliche Interaktivität (wie von Google angegeben) und hat fehlende Möglichkeiten aufgezeigt.

Die Google Search Console liefert zwar Daten zur Feldleistung, aber keine Echtzeitinformationen. Die Daten werden über einen Zeitraum von 28 Tagen aggregiert. Daher ist es schwierig, genau zu bestimmen, welche Interaktionen zu dem Zeitpunkt Probleme verursacht haben.

Es war eine Möglichkeit erforderlich, INP in Echtzeit zu erfassen, um die Interaktionen zu identifizieren, die sowohl am langsamsten als auch am häufigsten von Nutzern verwendet wurden, und sie in den Entwicklungsumgebungen des Teams zuverlässig zu reproduzieren. Ebenso wichtig war es, die Auswirkungen der vorgenommenen Änderungen zu verstehen. Es sollte nicht nur ermittelt werden, welche Korrekturen geholfen haben, sondern auch, welche Anpassungen die Situation unbeabsichtigt verschlechtert haben.

Aus diesen Gründen wurde eine Reihe von Tools verwendet, um die Probleme zu diagnostizieren und zu beheben. Die wichtigsten waren:

  • Google Chrome-Entwicklertools, insbesondere der Tab „Leistung“.
  • Ein benutzerdefiniertes RUM-System (Real User Monitoring), das vom Fotocasa-Team in Datadog mit der Web-Vitals-Bibliothek erstellt wurde.
  • React Developer Tools

Tools zur Diagnose des Problems

Die folgenden Tools wurden verwendet, um INP-Leistungsprobleme zu diagnostizieren und zu beheben.

Google Chrome-Entwicklertools

Eine hervorragende Möglichkeit, Probleme im Zusammenhang mit den Core Web Vitals in einer Webanwendung zu erkennen und zu reproduzieren, ist der Tab „Leistung“ in den Google Chrome-Entwicklertools. Auf dem Tab „Leistung“ werden Core Web Vitals-Messwerte automatisch gemessen. Sie erhalten sofortiges Feedback zu Messwerten für Ladezeiten, Interaktivität und Layoutverschiebungen. Die Werte stimmen im Großen und Ganzen mit den Werten überein, die in anderen Google-Tools für diese Messwerte angegeben werden.

Der Tab „Leistung“ in den Google Chrome-Entwicklertools mit einer Zeitachse mit verschiedenen Leistungsmesswerten wie LCP, FID und CLS sowie CPU- und Netzwerkaktivität.
Abb. 2. Der Tab „Leistung“ in den Google Chrome-Entwicklertools.

Um INP-Probleme zu identifizieren und zu beheben, drosselte das Fotocasa-Team in der Regel die CPU, um die Leistung von Geräten mit niedriger und mittlerer Qualität zu simulieren. So konnte das Fotocasa-Team beobachten, wie sich die Seite unter eingeschränkteren Bedingungen verhält. Die Sitzung wurde dann mit dem Profiler aufgezeichnet und die Traces wurden sorgfältig analysiert. Dabei wurde der Fokus auf die Nutzerinteraktion gelegt, um Leistungsprobleme zu identifizieren.

Der Tab „Leistung“ in den Google Chrome-Entwicklertools mit dem Drop-down-Menü „CPU-Verlangsamung“ und Optionen wie „4-fache Verlangsamung“ und „6-fache Verlangsamung“.
Abbildung 3. Der Tab „Leistung“ in den Google Chrome-Entwicklertools mit dem Drop-down-Menü für die CPU-Verlangsamung.

Bei der Ermittlung von Engpässen ist es besonders hilfreich, die INP-Unterbereiche und die Aufgaben zu untersuchen, die der Browser in den einzelnen Bereichen ausführt. Im folgenden Bild ist beispielsweise zu sehen, dass der INP aufgrund von zwei Stilneuberechnungen, die durch Stiländerungen im Textkörper des Dokuments verursacht werden, recht hoch ist.

Der Tab „Leistung“ in den Google Chrome-Entwicklertools zeigt eine lange Aufgabe im Profiler. Die Details weisen auf zwei Neuberechnungen des Stils hin, die einen hohen INP verursachen.
Abb. 4. Der Tab „Leistung“ in den Google Chrome-Entwicklertools mit dem ausgefüllten Profiler.

Fotocasa hat ein System eingerichtet, um den INP und andere Core Web Vitals-Messwerte zu erfassen. So können Leistungsprobleme schnell erkannt und behoben werden. Wenn ein Messwert einen bestimmten Grenzwert überschreitet (basierend auf den von Google definierten Bereichen), wird die Attribution protokolliert, damit das Problem analysiert und behoben werden kann.

Für dieses System wurde die web-vitals-Bibliothek verwendet, um diese Messwerte von echten Nutzern so zu erfassen, dass sie genau mit der Art und Weise übereinstimmen, wie sie von Chrome gemessen und an andere Google-Tools (z. B. Bericht zur Nutzererfahrung in Chrome, PageSpeed Insights, Geschwindigkeitsbericht der Search Console) gemeldet werden.

Um einen umfassenden Überblick zu erhalten und die Daten zentral zu erfassen, nutzte Fotocasa Datadog. So konnte das Team fundierte, datengestützte Entscheidungen treffen. Die benutzerdefinierten Messwerte sorgen für Kosteneffizienz und ermöglichen es, fast alle Nutzer auf der Fotocasa-Website besser zu erfassen.

Das Datadog-Dashboard von Fotocasa mit verschiedenen Leistungsmesswerten, darunter INP, LCP und CLS, im Zeitverlauf.
Abbildung 5. Fotocasa Datadog Performance RUM-Dashboard.
Datadog-Dashboard mit Grafiken für die Messwerte für Eingabeverzögerung, Verarbeitungsdauer und Darstellungsverzögerung.
Abbildung 6. Messwerte für Eingabeverzögerung, Verarbeitungsdauer und Darstellungsverzögerung.

So kann das Fotocase-Team schnell prüfen, ob sich die Änderungen auf die Messwerte auswirken oder ob unvorhergesehene Änderungen auftreten, die die Messwerte beeinträchtigen könnten. Der INP-Messwert kann dann in Teile wie Eingabeverzögerung, Verarbeitungsdauer und Darstellungsverzögerung unterteilt werden, um genau zu ermitteln, welcher Teil der Interaktion hauptsächlich für lange Interaktionszeiten verantwortlich ist.

Ein Diagramm von Datadog, das einen plötzlichen Anstieg der INP-Werte zeigt, was auf eine Anomalie hindeutet.
Abbildung 7. Im Dashboard wurde eine INP-Anomalie erkannt.
Ein Monitoralarm in Datadog, der eine erkannte INP-Anomalie anzeigt.
Abb. 8. Im Monitoralarm wurde eine INP-Anomalie erkannt.

Nachdem Fotocasa Anomalien wie die in Abbildung 7 und 8 dargestellte erkannt hatte, reagierte das Unternehmen umgehend und nutzte OpenSearch, ein weiteres Tool, mit dem sich der Ort der Änderung genau bestimmen ließ. Die von der Web Vitals-Bibliothek bereitgestellten Daten haben dazu beigetragen, das Ziel zu identifizieren (das DOM-Element, das möglicherweise für einen erhöhten Messwertwert verantwortlich ist), und dem Team geholfen, sich intensiver auf die Behebung des Problems zu konzentrieren.

OpenSearch-Dashboard mit Daten aus der Web Vitals-Bibliothek, mit denen ermittelt wird, welche DOM-Elemente sich auf den INP-Messwert auswirken.
Abbildung 9. OpenSearch-Dashboard, um zu ermitteln, welches Ziel sich auf den INP-Messwert auswirkt.

Außerdem können verschiedene Filter wie Seitentyp, Gerät oder Ladestatus definiert werden, um Szenarien zu optimieren und genauer zu verstehen, wie sich INP auswirkt.

React Developer Tools

Mit den React Developer Tools wurden die Debugging-Funktionen von Fotocasa verbessert. Sie bieten eine leistungsstarke Funktion, mit der Sie Komponenten, die neu gerendert wurden, visuell hervorheben können.

Diese Funktion kann auf dem Tab Profiler aktiviert werden. Klicken Sie dort in der oberen Leiste auf das Zahnrad, rufen Sie den Tab Allgemein auf und setzen Sie ein Häkchen bei Aktualisierungen beim Rendern von Komponenten hervorheben. Wenn diese Option aktiviert ist, werden Komponenten hervorgehoben, wenn sie neu gerendert werden.

Das Einstellungsfeld in React Developer Tools, in dem das Kästchen „Highlight updates when components render“ (Updates hervorheben, wenn Komponenten gerendert werden) angeklickt ist.
Abbildung 10. Die Profiler-Konfiguration in den React Developer Tools.

Ursache für das erneute Rendern herausfinden

Sobald eine Komponente identifiziert wurde, die neu gerendert wurde, lautet die nächste Frage: „Warum ist das passiert?“ React DevTools beantwortet dies mit einem hilfreichen Tooltip in der Flammenübersicht.

Um auf diese Informationen zuzugreifen, müssen Sie eine Profiler-Sitzung aufzeichnen. Durch die Analyse der Profiler-Ausgabe erhalten Sie hilfreiche Informationen:

  • Rechts oben wird die Anzahl der React-Commits angezeigt.
  • Das Flammen-Diagramm stellt den Komponentenbaum visuell dar. Graue Bereiche stehen für Komponenten, die nicht neu gerendert wurden. Jeder Balken steht für einen Moment, in dem sich der React-Komponentenbaum geändert hat und eine entsprechende Änderung im DOM übernommen wurde.
  • Wenn Sie den Mauszeiger auf eine Komponente im Flammen-Diagramm bewegen, wird unter der Überschrift Why did this render? (Warum wurde das gerendert?) der Grund für das erneute Rendern angezeigt.

Gründe für das erneute Rendern einer Komponente können sein:

  • Die Komponente wurde zum ersten Mal gerendert.
  • Kontext geändert
  • Hooks geändert
  • Requisiten geändert
  • Bundesland wurde geändert
  • Die übergeordnete Komponente wurde gerendert.
Der Profiler der React-Entwicklertools zeigt ein Flame-Diagramm. Eine Kurzinfo ist für eine Komponente geöffnet und erklärt, dass sie neu gerendert wurde, weil sich Hooks geändert haben.
Abbildung 11. Der Bereich „Render“ im Profiler der React-Entwicklertools.

Rendering-Zeit herausfinden

Die Farben in der Flammengrafik vermitteln wichtige Informationen. Farben wie verschiedene Blautöne deuten darauf hin, dass für eine Komponente im Vergleich zu anderen Komponenten eine relativ kurze Rendering-Zeit erforderlich war. Farben wie Orange und Rot bedeuten, dass für eine Komponente mehr Rendering-Zeit benötigt wurde.

Der Profiler der React-Entwicklertools zeigt ein Flame-Diagramm, in dem die Farben die Rendering-Zeit angeben. Blautöne stehen für kürzere Zeiten und Orange-/Rottöne für längere Zeiten.
Abbildung 12. Die Rendering-Zeit, wie sie im Profiler der React-Entwicklertools angezeigt wird.

So hat das Fotocasa-Team das Problem behoben

Unnötige Renders entfernen

Rerenderings erfolgen immer dann, wenn React die Benutzeroberfläche mit neuen Daten aktualisieren muss. Dies geschieht in der Regel durch eine Nutzeraktion, eine API-Antwort oder andere wichtige Ereignisse, die eine Aktualisierung der Benutzeroberfläche erfordern. Da bei jedem erneuten Rendern auch JavaScript ausgeführt wird, kann es bei zu vielen gleichzeitigen Rendervorgängen – insbesondere in einer großen Komponentenstruktur – zu einer Blockierung des Haupt-Threads und damit zu Leistungsproblemen kommen.

Es gibt zwei Arten von Rerendern:

  • Erforderliche Renders: Wenn eine Komponente wirklich aktualisiert werden muss, weil sie neue Daten enthält oder verwendet.
  • Unnötige Renders: Wenn eine Komponente ohne wesentliche Änderung aktualisiert wird, liegt das häufig an einer ineffizienten Statusverwaltung oder einer falschen Verarbeitung von Attributen.

Einige unnötige Renders sind in der Regel kein Problem, da React schnell genug ist, dass Nutzer sie in der Regel nicht bemerken. Wenn sie jedoch zu oft oder in einem umfangreichen Komponentenbaum auftreten, können sie die Nutzerfreundlichkeit beeinträchtigen und sich negativ auf den INP der Seite auswirken.

Das war beim Fotocasa-Team der Fall. Sie stellten fest, dass die Website viele unnötige Renders hatte. Diese traten in zwei Hauptszenarien auf:

  • Beim Seitenaufbau: Die Anzahl der langen Aufgaben im Hauptthread wurde erhöht und die erste Interaktion verzögert, was sich negativ auf den INP der Seite auswirkte.
  • Bei Nutzerinteraktionen: Die Verarbeitungszeit der meisten Interaktionen wurde verlängert, was sich auch negativ auf INP ausgewirkt hat.

Viele unnötige Renders wurden auf der Fotocasa-Website optimiert. Eine der größten Optimierungen wurde auf der Suchseite vorgenommen. Beim Laden der Seite wurden drei unnötige Renders ausgeführt. Nachdem diese entfernt wurden, wurden die folgenden Ergebnisse beobachtet:

  • Weniger lange Aufgaben (siehe Abbildung unten)
  • Kürzere Total Blocking Time (siehe Abbildung 14 und 15)
Zwei Hauptthread-Snapshots aus den Chrome-Entwicklertools. Im oberen Snapshot sind vor den Optimierungen mehr lange Aufgaben zu sehen, im unteren Snapshot nach dem Entfernen unnötiger Renders weniger.
Abbildung 13. Snapshot des Haupt-Threads mit und ohne unnötige Renders.
Ein Lighthouse-Bericht zur mobilen Leistung mit einer Total Blocking Time von 1.080 ms, der auf Leistungsprobleme aufgrund unnötiger Renders hinweist.
Abb. 14. Der Lighthouse-Leistungsbericht für Mobilgeräte, der unnötige Renders zeigt.
Ein Lighthouse-Bericht zur mobilen Leistung, der eine deutlich verkürzte Total Blocking Time nach dem Entfernen unnötiger Renders zeigt.
Abb. 15. Der Lighthouse-Leistungsbericht für Mobilgeräte ohne unnötige Renders.

Zustands-Colocation

Wenn der React-Status nicht richtig platziert wird, kann dies die Leistung einer Anwendung beeinträchtigen und die Benutzeroberfläche kann sich langsam anfühlen. Wenn sich der Status einer Komponente ändert, werden ihre untergeordneten Komponenten standardmäßig neu gerendert, es sei denn, es wird ein Escape Hatch verwendet (z. B. „memo“).

Wie im vorherigen Abschnitt erläutert, sind Rerenders nicht grundsätzlich schlecht. Wenn jedoch die gesamte Seite aufgrund einer bestimmten Statusaktualisierung neu gerendert wird, kann dies zu langsameren Interaktionen führen, da DOM-Aktualisierungen nach dem Rendern erfolgen.

Auf der Suchseite wird beispielsweise ein Dialogfeld mit allen Filtern angezeigt, wenn auf eine Schaltfläche geklickt wird.

Die Filterleiste auf der Fotocasa-Suchseite mit einer Schaltfläche zum Öffnen eines Dialogfelds mit allen Filtern.
Abbildung 16. Filterleiste von Fotocasa.

Der Status, der den geöffneten Zustand des Dialogfelds in diesem Fall steuert, wurde auf der Suchseite platziert. Als sich dieser Status änderte, wurde die gesamte Seite neu gerendert, was zu einem schlechten INP führte, insbesondere auf langsameren Geräten, wie beim Verwenden von CPU-Drosselung in den DevTools zu sehen war:

CPU-Drosselung INP
4-fache Verlangsamung 440 Millisekunden (Optimierung erforderlich)
6-fache Verlangsamung 832 Millisekunden (schlecht)

Wenn Sie den Status so nah wie möglich an der Komponente ändern, die die Änderung auslöst, wird dieses Problem behoben. In diesem speziellen Fall könnte der Status in der Schaltflächenkomponente der Filter platziert werden. Wenn sich der Status ändert, wird nur die Schaltfläche neu gerendert.

CPU-Drosselung INP
4-fache Verlangsamung 64 Millisekunden (gut)
6-fache Verlangsamung 232 Millisekunden (Optimierung erforderlich)

Unnötige Status entfernen

Status sollten keine redundanten oder doppelten Informationen enthalten. Wenn das der Fall ist, kann es zu unnötigen Rerenders und Problemen kommen.

In der Filterleiste von Fotocasa wird beispielsweise Text angezeigt, der die Anzahl der für eine bestimmte Suche angewendeten Filter angibt:

Die Fotocasa-Filterleiste mit einer Schaltfläche mit der Aufschrift „Filter“ und einer Zahl, die die Anzahl der angewendeten Filter angibt.
Abbildung 17. Schaltfläche und Zähler für Fotocasa-Filter

Die Anzahl der angewendeten Filter wird anhand des Status der Anwendung berechnet. Dies führte jedoch nicht nur zu einem unnötigen erneuten Rendern der gesamten Komponente, sondern in bestimmten Fällen auch zu einer Layoutverschiebung, da diese Komponente serverseitig gerendert wird:

const [filtersCount, setFiltersCount] = useState(DEFAULT_COUNTER)

useEffect(() => {
  const counter = filters
    ? Object.keys(filters)
        ?.reduce(reducerCounter, [])
        ?.filter((param) => searchParams?.[param]).length
    : DEFAULT_COUNTER

  setFiltersCount(counter)
}, [searchParams]);

Um dieses Problem zu beheben, wurde der Wert aus dem Filterobjekt mithilfe einer Variablen anstelle des Status abgeleitet:

const counter = filters
    ? Object.keys(filters)
        ?.reduce(reducerCounter, [])
        ?.filter((param) => searchParams?.[param]).length
    : DEFAULT_COUNTER;

Kostenintensive Renderings reduzieren

Wenn in einer React-Anwendung eine Interaktion stattfindet, wird normalerweise eine Statusänderung ausgelöst. Wie bereits erwähnt, wird eine Komponente zusammen mit allen untergeordneten Komponenten neu gerendert, wenn sich ihr Status ändert.

Wenn eine dieser Komponenten langsam gerendert wird, wirkt sich das negativ auf den INP der Seite aus, da wahrscheinlich eine lange Aufgabe generiert wird und das Aktualisieren des DOM länger dauert.

Das Fotocasa-Team hat versucht, zeitaufwendige Berechnungen in der Renderfunktion von Komponenten so weit wie möglich zu minimieren. Die Chrome-Entwicklertools und die React-Entwicklertools waren sehr hilfreich, um langsame Rendering-Vorgänge zu erkennen.

Codeausführung verzögern

Neben der Optimierung der Renderfunktion von Komponenten wurden auch andere Funktionen optimiert, um lange Aufgaben so weit wie möglich zu minimieren. Einige Aufgaben konnten jedoch nicht optimiert werden, da sie von Drittanbietercode abhängig waren.

Ein Beispiel war die Analyse. In diesem Fall wurde beschlossen, die Ausführung des Analyse-Codes zu verzögern und DOM-Aktualisierungen bei Nutzerinteraktionen zu priorisieren. Dazu verwendete das Fotocasa-Team eine Bibliothek namens „idlefy“, die dafür sorgte, dass der Analysecode auch dann ausgeführt wurde, wenn der Browser sofort danach geschlossen wurde.

Leistungskultur

Leistungsoptimierung ist keine einmalige Aufgabe, sondern muss bei jeder Funktion berücksichtigt werden, die in der Produktion veröffentlicht wird. Alle Teammitglieder müssen auf dem gleichen Stand sein, da es sonst fast zwangsläufig zu Regressionen bei den Core Web Vitals kommt.

Um den Überblick zu behalten, tauschte das Fotocasa-Team aktiv Wissen aus und schuf einen klaren Rahmen für die Identifizierung von Leistungsproblemen auf Grundlage der Datadog RUM-Daten von Fotocasa, einschließlich der Reproduktion. Im RUM-System wurden Benachrichtigungen für Core Web Vitals, insbesondere INP, eingerichtet, die das Fotocasa-Team direkt in Slack benachrichtigen. Bei diesem Ansatz wurde die Leistung immer im Blick behalten und Probleme konnten erkannt werden, bevor sie zu Regressionen wurden.

Ergebnisse

Um den INP-Wert bei Fotocasa zu verbessern, waren sowohl technische Optimierungen als auch kulturelle Veränderungen erforderlich. Durch das Eliminieren unnötiger Neudarstellungen, das Optimieren der Platzierung von Status, das Reduzieren aufwendiger Darstellungen und das Zurückstellen nicht kritischen Codes konnte das Fotocasa-Team alle Desktop-Seiten von „Verbesserungsbedarf“ auf „Gut“ umstellen und die mobilen Seiten deutlich verbessern, indem es fast alle Seiten mit „Schlecht“ und „Verbesserungsbedarf“ auf „Gut“ umstellte.

Google Search Console mit den Core Web Vitals für Desktop von Fotocasa nach INP-Verbesserungen.
Abb. 18. Google Search Console mit den Core Web Vitals für Desktop von Fotocasa nach INP-Verbesserungen.

Diese Änderungen haben die Nutzerfreundlichkeit von Fotocasa insgesamt verbessert und in Kombination mit anderen Initiativen zu einer Steigerung der Kontakt- und Telefon-Lead-Anzeigen um 27% geführt. So konnten die wichtigsten Geschäftskennzahlen des Unternehmens direkt verbessert werden.

Durch das Echtzeit-Monitoring mit Datadog konnte das Fotocasa-Team die INP-Verbesserungen validieren, Anomalien schnell erkennen und Regressionen verhindern. Fotocasa hat es nicht nur geschafft, diese Ziele zu erreichen, sondern auch die Web-Performance in die Entwicklungskultur zu integrieren. So bleiben INP und Core Web Vitals bei jeder Veröffentlichung eine Priorität.