Audit und Beratung · Prijsvrij

CLS von 0,4 auf 0,06 in einem Urlaubs-Buchungs-Flow

Die Layout Shifts lagen im Buchungs-Flow, und die meisten passierten nach dem ersten Laden der Seite.

1,8sLCP, vorher 2,6s
0,06CLS, vorher 0,4
160msINP, vorher 215ms
KundePrijsvrij, Prijsvrij.be und D-reizen, Urlaubsbuchungen
PlattformEine Single Page Application
LeistungAudit im März 2026, danach jedes Quartal Beratung
Der Kunde

Eine Single Page Application mit Layout Shifts im Buchungs-Flow

Prijsvrij ist ein niederländisches Reiseportal: Urlaub suchen, vergleichen und buchen. Die gesamte Website ist eine Single Page Application, und dasselbe Team betreibt auch Prijsvrij.be und D-reizen.

Ich war an zwei Tagen für je vier Stunden vor Ort. Am ersten Tag habe ich das Audit gemacht. Am zweiten Tag bin ich die Ergebnisse mit dem Team durchgegangen und habe Schritt für Schritt erklärt, wie sie die dringendsten Probleme zuerst beheben.

Prijsvrij homepage
Was wir fanden, was wir getan haben

Der erste Screen, der Buchungs-Flow und die Klicks

Die meisten Layout Shifts passierten bei Soft Navigations: Die App tauscht Inhalte aus, ohne eine neue Seite zu laden. Ein Lighthouse-Lauf auf der Startseite sieht das nie. Echte Besucher, die sich durch eine Buchung klicken, schon – und CrUX rechnet diese Shifts der URL zu, die sie zuerst geöffnet haben.

Was nicht stimmte
Was wir getan haben
LCP
Das CSS war so aufgeteilt, dass es den ersten Screen blockierte. Die Preloads zeigten auf Dateien, die der erste Screen gar nicht brauchte. Es luden Bilder, die im ersten Screen gar nicht zu sehen waren, und das Hero-Element wurde erst gefunden, als das JavaScript lief. Third-Party-Tags und Fonts luden ebenfalls früh.
Das Hero-Element bekam einen Preload und fetchpriority="high". Pro Seite haben wir entschieden, was Vorrang hat. Der LCP sank von 2,6 auf 1,8 Sekunden.
CLS
Während die App die Urlaubsdaten lud – vor allem den Flug –, zeigte sie eine Lade-Animation. Traf der echte Inhalt ein, schob er das Layout weg. Zwischen den Schritten passierte bei Bildern, Bannern und Hinweisen dasselbe.
Der Ladezustand bekam die finale Größe des Flug-Blocks. Bilder, Banner und Hinweise erhielten feste Maße. Der CLS sank von 0,4 auf 0,06.
INP
Ein Filter-Klick berechnete und renderte alle Ergebnisse neu. Der Datepicker baute Preise für Monate direkt im Klick auf. Die Auswahl von Reisenden oder Zimmern berechnete die gesamte Buchung neu. Tracking lief in denselben Klicks.
Ich habe den Entwicklern in ihrem eigenen Code gezeigt, was jeder Klick ausführt – und wie sie zuerst den Screen aktualisieren und den Rest danach ausführen. Der INP sank von 215 auf 160 ms.
Prijsvrij's booking flow: most layout shifts happened after the first load, where a Lighthouse run of the homepage doesn't look
Nach dem Audit

Das Audit habe ich Ende März 2026 abgeliefert. Am 15. April bin ich es mit ihren Entwicklern in Den Bosch durchgegangen, eine Woche später online. CLS war der schwierige Teil, mit mehr Ursachen als sonst bei so einem Setup. Ihre Entwickler haben das auf allen drei Websites behoben. Im Mai wurde der Desktop-CLS auf jeder einzelnen grün.

0,100,250,13März 2026Apr0,38MaiJunJulAugSepOkt0,06prijsvrij.nl, CLS auf Desktop, p75
0,100,12März 2026Apr0,20MaiJunJulAugSepOkt0,05prijsvrij.be, CLS auf Desktop, p75
0,100,11März 2026Apr0,14MaiJunJulAugSepOkt0,04d-reizen.nl, CLS auf Desktop, p75
Die drei Websites im CrUX, März bis Oktober 2026. Ein Balken pro Woche, jeweils die 28 Tage bis zu diesem Datum, p75. Grün ist gut, Orange braucht Optimierung, Rot ist schlecht.
Seitdem

Eines Morgens im Juni mailte mir ihr Frontend-Lead. Er hatte die letzten Wochen an prijsvrij.nl getüftelt, auf Basis der CoreDash-Daten über die Claude-Code-Anbindung. Die Kurven zeigten in die richtige Richtung. Könnte D-reizen auch mit rein? Keine Stunde später waren D-reizen und Prijsvrij.be beide in CoreDash.

Als Nächstes ist der INP dran. Als ich ihn mir Ende Juni ansah, erkannte ich das Muster: Ich habe das schon oft gesehen. Ein bewährter Schritt-für-Schritt-Plan behebt es, solange jeder Schritt exakt ausgeführt wird. Das erledigt den größten Teil. Erst dann zeigen sich die darunterliegenden Probleme, und die sind immer kleiner. Also schlug ich vor, hands-on zu arbeiten: kleine, chirurgische Änderungen, weniger Theorie, mehr Machen. Im Juli trafen wir uns bei ihnen im Büro, inklusive Mittagessen. Seitdem treffen wir uns jedes Quartal.

Der mobile LCP steigt in der Urlaubszeit, wenn viel Traffic von Leuten kommt, die selbst im Urlaub sind. Er bleibt deutlich unter 2,5 Sekunden und sinkt bereits wieder.

Was wir gelernt haben

Eine Lade-Animation verschiebt den Layout Shift nur

Die Animation sah so aus, als würde sie die Wartezeit überbrücken. Der Shift kam in dem Moment, als sie Platz für die Flugdetails machte.

Tracking im Klick kostet jeden Klick

Ein Tag im Klick-Handler läuft, bevor der Screen sich ändern kann. Liegt er hinter dem Update, sieht der Besucher das Ergebnis zuerst – und der Tag läuft trotzdem.

Eine Single Page Application verändert sich ständig

Jedes Release bringt Komponenten und Tags mit, die der letzte Check nie gesehen hat. Genau deshalb komme ich jedes Quartal wieder.

Arjen Karel

Layout Shifts in einer Single Page App, die Lighthouse nie sieht?

Schick mir die URL deines Buchungs- oder Checkout-Flows. Ich klicke mich wie ein Besucher durch, inklusive Soft Navigations.

Prijsvrij: CLS von 0,4 auf 0,06 in einem Buchungs-Flow Core Web Vitals Prijsvrij: CLS von 0,4 auf 0,06 in einem Buchungs-Flow