INP Is the Core Web Vital That Catches PHP Sites Out
Server-rendered PHP and Laravel sites usually pass LCP comfortably, then fail INP. Here is why responsiveness is the harder metric, and what actually moves it.
Most PHP and Laravel sites I audit pass Largest Contentful Paint without much trouble. Server-rendered HTML arrives fast, the hero image is usually the only heavy asset, and a decent host does the rest. Then they fail Interaction to Next Paint, and the owner cannot work out why a "fast" site is being marked slow.
What INP actually measures
INP replaced First Input Delay as a Core Web Vital. The difference is the whole story. FID measured the delay before the browser began processing the first interaction — a forgiving metric that most sites passed by default. INP measures the full latency of every interaction on the page: click, tap, key press, from the moment of input until the next frame is painted.
A "good" INP is under 200 milliseconds. Because it looks at the worst interactions rather than the first, INP catches everything FID politely ignored.
Why server-rendered sites fail it
The irony is that a traditional PHP site fails INP for reasons that have nothing to do with PHP. The server has finished its work before the browser starts misbehaving.
- Third-party widgets. Live chat, analytics, consent banners, review embeds. A chat widget is one of the most common INP offenders on small business sites — it loads late, hydrates on the main thread, and delays every click made while it settles.
- jQuery-era event handling. Delegated handlers bound to
document, running selector matching on every click across a large DOM. - Long tasks. Any single block of JavaScript running over 50ms blocks the main thread. Carousels, sliders and table sorters are frequent culprits.
- Layout thrash. Reading a layout property, writing a style, then reading again inside the same handler forces repeated synchronous reflow.
Measure the field, not the lab
This is where most people go wrong. Lighthouse gives you a lab score on your machine, on your connection, with no real interactions. INP is a field metric — it comes from real users on real devices, most of them on mid-range Android phones with a fraction of your laptop's single-core performance.
Use the Chrome User Experience Report data in Search Console, or the web-vitals library reporting to your own endpoint. Lab tools help you form a hypothesis; only field data tells you whether you fixed it.
Fixes that move the number
Break up long tasks
Yield to the main thread so the browser can paint between chunks of work. Splitting a 300ms handler into segments that yield does not make it finish sooner, but it lets the browser respond in between — which is exactly what INP scores.
Defer everything non-essential
Third-party scripts rarely need to run during page load. Load chat widgets, analytics and review embeds after the page is interactive, or on first user intent — a scroll, or a click on a placeholder button. On one site, deferring the chat widget alone was the single biggest INP improvement available.
Stop doing work in the handler
Update state, then let the rendering happen. Batch DOM reads before writes. Move genuinely heavy computation to a Web Worker.
Ship less JavaScript
Modern frameworks are converging on partial hydration — "island architecture" — where only the interactive parts of a page hydrate rather than the entire tree, which cuts main-thread execution substantially. In Blade-rendered Laravel you get this by default, provided you resist bolting a heavy client framework onto pages that do not need one. Alpine.js for a dropdown is fine; a full SPA runtime to toggle a menu is not.
The Laravel-specific note
Livewire is convenient, and it is also a network round-trip on interaction. That is fine for an admin panel and questionable for a public product page where INP is being measured. Reserve it for authenticated interfaces; keep public pages on plain Blade with small, targeted JavaScript.
Where to start
Pull your field INP from Search Console, identify the worst page, then record an interaction trace in Chrome DevTools while clicking the element real users click. In most cases you will find one third-party script or one oversized handler responsible for the bulk of it. Core Web Vitals remain a lightweight ranking signal rather than a dominant one — but between two comparable pages, the faster one wins, and users notice responsiveness long before they notice rankings.