[{"data":1,"prerenderedAt":193},["ShallowReactive",2],{"seo-verification":3,"blog-core-web-vitals-inp-web-hosting-en":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-core-web-vitals-inp-web-hosting-en",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"publishedAt":20,"category":21,"categories":26,"featuredImage":28,"bgImage":29,"posterImage":30,"relatedSolution":28,"intro":31,"sections":32,"ctaTitle":126,"ctaBody":127,"ctaButton":128,"ctaUrl":129,"relatedPosts":130},346,"core-web-vitals-inp-web-hosting",{"fr":12,"en":10,"ar":13,"es":14},"core-web-vitals-inp-hebergement","core-web-vitals-inp-web-hosting-ar","core-web-vitals-inp-alojamiento-web","Core Web Vitals and INP: what your hosting actually changes","LCP, INP, CLS — the 2026 thresholds, their connection to server TTFB, and why a well-configured VPS succeeds where shared hosting consistently fails.",12,0,false,"2026-09-10T00:00:00+00:00",{"id":22,"name":23,"slug":24,"color":25,"icon":24},3,"Deployment","deploiement","bg-success\u002F10 text-success",[27],{"id":22,"name":23,"slug":24,"color":25,"icon":24},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fcore-web-vitals-inp-hebergement-poster.svg","When a client sends you a red PageSpeed report, the first cause to rule out is not the theme or the JavaScript — it is server latency. A TTFB above 600 ms leaves less than 1 900 ms for everything else, making a sub-2.5-second LCP nearly impossible on a standard connection. In 2026, 43% of sites still fail the 200 ms INP threshold — a metric that directly affects Google search rankings. This article covers the full causal chain from hosting to field metrics, and the concrete server-side actions needed to pass every threshold.",[33,37,47,50,86,114,117,120,123],{"type":34,"title":35,"body":36},"h2","The three Core Web Vitals metrics and their 2026 thresholds","Google measures user experience through three main metrics, collectively known as Core Web Vitals. Each has a Good threshold and a Needs Improvement threshold beyond which rankings are affected.\n\n**LCP — Largest Contentful Paint.** Measures the render time of the largest visible element (hero image, main text block). Good threshold: ≤ 2 500 ms. Needs Improvement: between 2 500 ms and 4 000 ms. Above 4 000 ms: Poor.\n\n**INP — Interaction to Next Paint.** Introduced as a replacement for FID, INP measures the latency between a user gesture (click, keystroke, tap) and the next visual render. Good threshold: ≤ 200 ms. Needs Improvement: between 200 ms and 500 ms. Above 500 ms: Poor.\n\n**CLS — Cumulative Layout Shift.** Measures the visual instability of the page — block shifts during loading. Good threshold: ≤ 0.1. Needs Improvement: between 0.1 and 0.25. Above 0.25: Poor.\n\nThese thresholds apply to field data (CrUX), not to lab scores. A PageSpeed Insights lab score of 90 does not guarantee that real users pass the threshold — this distinction matters for agencies reporting metrics to clients.",{"type":38,"items":39},"ul",[40,41,42,43,44,45,46],"**Degraded search ranking** — Google has incorporated Core Web Vitals into its Page Experience signal since 2021; a site rated Poor on LCP or INP loses positions against a comparable competitor whose metrics are in the green.","**Lower mobile CTR** — well-ranked results carry an implicit trust signal; a slow load perceived by the user after clicking increases the bounce rate and registers as a negative engagement signal.","**Reduced conversion rate** — each additional second of LCP beyond 2.5 s correlates with higher cart abandonment; for an e-commerce site, a 1 200 ms TTFB can erase a significant portion of SEO-generated revenue.","**Higher ad spend** — Google Ads Quality Score incorporates landing page experience; a Poor LCP degrades the score and raises CPC for the same keyword.","**Client loss for agencies** — when a client's monthly report shows a red INP, the question arrives immediately; without infrastructure capable of holding the thresholds, the agency cannot promise a lasting fix.","**Slower mobile indexing** — Googlebot mobile follows the same render delay as users; a high TTFB slows crawling and can delay indexation of new pages.","**Measurable user experience impact** — an INP above 500 ms makes interactions (menus, filters, forms) perceptibly slow; negative user feedback often precedes metric alerts.",{"type":34,"title":48,"body":49},"How TTFB blocks LCP: the causal chain","TTFB (Time to First Byte) is the time between the browser's HTTP request and receipt of the first byte of the server response. It is the incompressible floor for everything else.\n\nOn a standard mobile connection (median 4G), the browser has roughly 2 500 ms to reach the Good LCP threshold. From that budget, DNS resolution, the TLS handshake and TTFB are deducted first. A TTFB of 800 ms — common on a saturated shared host — leaves 1 700 ms for HTML download, parsing, loading blocking resources and rendering the LCP element. In practice, this budget is not enough.\n\nThe causal chain is: the server generates the page (PHP, database), then sends the first byte. If PHP-FPM is not enabled and the server uses mod_php in prefork mode, each request monopolises an entire Apache worker. Under load, workers are exhausted and requests queue. TTFB grows non-linearly — a saturated shared host can exceed 1 200 ms TTFB while showing 200 ms when idle.\n\nAdding a Redis object cache reduces this significantly: instead of executing 40 to 80 SQL queries to compose a WordPress page, the cache returns the precomputed result in milliseconds. Without Redis, every full-page cache miss (WP Rocket, W3TC) triggers a full regeneration that pushes TTFB well above 600 ms.\n\nHTTP\u002F3 (QUIC) reduces connection latency by eliminating the extra round-trip of the TCP+TLS handshake, which is particularly impactful on mobile and on lossy networks. Activation requires a server that supports QUIC — not available on all shared hosting environments.",{"type":51,"title":52,"headers":53,"rows":57},"comparison","Saturated shared hosting vs VPS with PHP-FPM and Redis",[54,55,56],"Criterion","Saturated shared hosting","VPS + PHP-FPM + Redis",[58,62,66,70,74,78,82],[59,60,61],"Median TTFB under load","800 – 1 200 ms","120 – 250 ms",[63,64,65],"PHP execution","mod_php prefork (shared worker)","PHP-FPM (dedicated pool, non-blocking)",[67,68,69],"Object cache","Not available or disabled","Local Redis socket, latency \u003C 1 ms",[71,72,73],"HTTP\u002F3 (QUIC)","Rarely available","Configurable on nginx \u002F Caddy",[75,76,77],"LCP score (field)","Needs Improvement to Poor frequent","Good achieved on standard connection",[79,80,81],"INP score (field)","Depends on client-side JS","Same JS, fewer network blocking events",[83,84,85],"Resource isolation","CPU and memory shared among clients","Dedicated resources, no noisy-neighbour effect",{"type":87,"title":88,"steps":89},"steps","Optimising the server stack from the hosting side",[90,93,96,99,102,105,108,111],{"title":91,"body":92},"Enable PHP-FPM instead of mod_php","On Apache, replacing mod_php with PHP-FPM and `mpm_event` removes worker blocking on slow requests. Check the active mode: `apache2ctl -M | grep php`. On nginx, PHP-FPM is the only available mode — ensure the pool is sized for the load (`pm.max_children` calculated from available RAM divided by average worker consumption).",{"title":94,"body":95},"Configure Redis as WordPress object cache","Install Redis on the server (`apt install redis-server` or via the distribution package manager). Enable a Unix socket rather than TCP to reduce latency: `unixsocket \u002Fvar\u002Frun\u002Fredis\u002Fredis.sock`. In WordPress, install a Redis object cache plugin and point it to the socket. Verify activation with `wp redis status` — the status should show `Connected`.",{"title":97,"body":98},"Enable Brotli and Gzip compression","Brotli delivers better compression than Gzip on text resources (HTML, CSS, JS). On nginx, check module availability: `nginx -V 2>&1 | grep brotli`. Without Brotli, Gzip remains effective: `gzip_comp_level 6; gzip_types text\u002Fplain text\u002Fcss application\u002Fjavascript application\u002Fjson image\u002Fsvg+xml;`. Enable pre-compressed serving (static `.gz` files) for resources that do not change.",{"title":100,"body":101},"Enable HTTP\u002F3 (QUIC) on nginx or Caddy","Caddy enables HTTP\u002F3 by default with no additional configuration. On nginx, availability depends on the compiled version: `nginx -V 2>&1 | grep http3`. Add to the `server` block: `listen 443 quic reuseport; add_header Alt-Svc 'h3=\":443\"; ma=86400';`. Open UDP port 443 in the firewall (`ufw allow 443\u002Fudp`). Validate with `curl --http3 -I https:\u002F\u002Fyourdomain.com`.",{"title":103,"body":104},"Configure browser cache headers","Static resources (images, fonts, versioned CSS, JS) should carry `Cache-Control: public, max-age=31536000, immutable`. HTML pages should carry `Cache-Control: no-store` or a short `max-age` if an upstream page cache is active. Verify headers in production: `curl -I https:\u002F\u002Fyourdomain.com\u002Fwp-content\u002Fthemes\u002Fmy-theme\u002Fstyle.css`.",{"title":106,"body":107},"Enable server-side page cache (if not handled by CDN)","A server-side page cache (nginx FastCGI cache, or Varnish module) returns precompiled HTML without touching PHP or the database. TTFB then drops below 50 ms for cached pages. Exclude cart, account and session-cookie pages from caching: `fastcgi_cache_bypass $cookie_woocommerce_items_in_cart;`.",{"title":109,"body":110},"Measure TTFB under real conditions with WebPageTest","Run a test from `webpagetest.org` selecting a point of presence close to the clients' geographic target. Choose a mobile profile (Moto G4 or equivalent) and a simulated 4G connection. In the results, read the TTFB column in the waterfall — it isolates server time from network time. Compare warm runs (cache present) and cold runs (cache flushed via the test parameter).",{"title":112,"body":113},"Verify real-world impact via CrUX and Search Console","PageSpeed Insights displays CrUX data for the analysed domain when available (sufficient traffic volume). Field metrics appear in the 'Field data' section — these are the only ones that matter to Google. In Search Console, the 'Page Experience' report aggregates URLs by status (Good \u002F Needs Improvement \u002F Poor) over a rolling 28-day window.",{"type":34,"title":115,"body":116},"Measuring correctly: WebPageTest vs PageSpeed Insights","WebPageTest and PageSpeed Insights measure different things, and confusing them leads to poor decisions.\n\nPageSpeed Insights runs a Lighthouse audit in the lab — controlled conditions, simulated device, simulated network. The displayed score (0 to 100) is a rating of optimisation opportunities, not a measure of real user performance. A site can score 95 in the lab and be rated Poor in field data if dynamic content or JavaScript interactions degrade real metrics. The PageSpeed Insights score is not Google's ranking signal.\n\nWebPageTest allows precise configuration of the geographic test point, device profile and network simulation. It exposes the full loading waterfall, DNS\u002FTCP\u002FTLS\u002FTTFB timings, and supports multi-step tests to measure INP on a simulated interaction. For diagnosing high TTFB, WebPageTest is the reference tool.\n\nCrUX data (Chrome User Experience Report) collects real metrics from Chrome users over 28 days. Available via PageSpeed Insights, Search Console, and the CrUX API directly. These are the data Google uses for ranking — not the Lighthouse score.",{"type":118,"body":119},"tip","Reading the CrUX report in Search Console: open the property, go to 'Page Experience', then 'Core Web Vitals report'. The report separates mobile and desktop. Click on 'Good URLs' or 'Poor URLs' to see which pages are affected. If data volume is insufficient (low-traffic site), CrUX data will not appear — use PageSpeed Insights on key URLs and note that the ranking impact remains real even without a Search Console report available. For low-traffic agency clients, focus on WebPageTest measurements and absolute thresholds rather than CrUX reports.",{"type":34,"title":121,"body":122},"Troubleshooting: four common cases","**TTFB correct but INP red.** A TTFB below 250 ms does not guarantee an INP under 200 ms. INP measures responsiveness to interactions, not initial loading. Common causes of high INP despite good TTFB: a JavaScript main thread blocked by third-party scripts (analytics, chatbots, ads) during the interactivity phase; Long Tasks (> 50 ms) that delay the render after a click; expensive Vue or React hydration on an SSR page. Diagnose in Chrome DevTools > Performance by recording an interaction and identifying long tasks on the main thread.\n\n**INP passes in lab but not in field.** Lab tools (Lighthouse, WebPageTest) measure INP on simulated interactions under controlled conditions. In field data, INP includes all interactions from all users, including those on low-end devices with third-party scripts loaded, active browser extensions and variable connectivity. An INP of 180 ms in the lab may exceed 500 ms in the field if a third-party script blocks the main thread during initial load. Identify third-party scripts with `webpagetest.org` and measure their impact on the main thread.\n\n**LCP slow despite Cloudflare.** Cloudflare caches static resources but does not cache HTML pages by default (unless explicitly configured via Page Rules or Cache Rules). If the LCP is driven by an HTML element (text or image included in the HTML), the HTML page TTFB still determines LCP. Check the `CF-Cache-Status` header in the HTTP response: `curl -I https:\u002F\u002Fyourdomain.com | grep CF-Cache-Status`. If the value is `DYNAMIC` or `BYPASS`, the page is not Cloudflare-cached and server TTFB applies in full.\n\n**CLS regressing after theme update.** CLS is sensitive to resources loading without specified dimensions (images without `width`\u002F`height`, web fonts causing FOIT\u002FFOUT, banners injected by JavaScript). After a theme update, systematically verify that images have explicit dimension attributes and that web fonts use `font-display: swap` or `optional`. Inspect the CLS recording session in PageSpeed Insights (Diagnostics section) to identify the shifting element.",{"type":34,"title":124,"body":125},"What the agency can promise its clients","A red PageSpeed report is not inevitable, but it is important to distinguish what belongs to hosting from what belongs to client code.\n\nOn the hosting side, measurable commitments are: TTFB below 250 ms under normal load conditions, PHP-FPM availability with a sized pool, active Redis object cache, and Brotli or Gzip compression on text resources. These four points cover the server-side portion of LCP and mechanically reduce the risk of exceeding 2 500 ms on a client-side-optimised page.\n\nINP remains partially under the responsibility of front-end code — third-party scripts, JavaScript hydration and long tasks do not depend on the hosting provider. What hosting can do for INP: reduce TTFB (less waiting time before JS begins executing), enable HTTP\u002F3 (less latency on blocking resources), and avoid CPU contention that would lengthen JavaScript tasks during SSR rendering.\n\nAn agency managing a client portfolio can guarantee server-side thresholds, document WebPageTest and CrUX measurements per domain, and isolate regressions to their source — theme, plugin, third-party script or server capacity. That isolation capability is what distinguishes an agency that reacts to PageSpeed reports from one that controls them.","Pass Core Web Vitals for all your clients","Manage your clients' SEO with infrastructure that keeps TTFB under 250 ms. Centralised portfolio, configurable VPS, responsive technical support.","Discover the agency space","\u002Fsolutions\u002Fagences",[131,152,175],{"id":132,"slug":133,"slugs":134,"title":138,"excerpt":139,"readTime":22,"views":18,"isPinned":19,"publishedAt":140,"category":141,"categories":147,"featuredImage":28,"bgImage":29,"posterImage":149,"relatedSolution":150},73,"host-wordpress-on-your-own-vps",{"fr":135,"en":133,"ar":136,"es":137},"heberger-wordpress","استضافة-wordpress-على-خادم-vps-الخاص-بك","alojar-wordpress-en-un-vps","Host WordPress on your own VPS","Host WordPress on your VPS for maximum performance and control: Docker, MariaDB, caching, reverse proxy and SSL.","2026-04-08T00:00:00+00:00",{"id":142,"name":143,"slug":144,"color":145,"icon":146},7,"Self-hosting","self-hosting","bg-indigo-500\u002F10 text-indigo-400","cloud",[148],{"id":142,"name":143,"slug":144,"color":145,"icon":146},"\u002Fblog\u002Fcovers\u002Fheberger-wordpress-poster.svg",{"categorySlug":144,"appSlug":151},"wordpress",{"id":153,"slug":154,"slugs":155,"title":159,"excerpt":160,"readTime":161,"views":18,"isPinned":19,"publishedAt":162,"category":163,"categories":169,"featuredImage":28,"bgImage":29,"posterImage":171,"relatedSolution":172},58,"hosting-redis-on-a-vps",{"fr":156,"en":154,"ar":157,"es":158},"heberger-redis-vps","استضافة-redis-على-خادم-vps","alojar-redis-en-un-vps","Hosting Redis on a VPS: the complete guide","Deploy Redis on your Cloud VPS: RAM\u002FCPU requirements, security (ACL, TLS), RDB\u002FAOF persistence, troubleshooting, and high availability.",10,"2026-04-23T00:00:00+00:00",{"id":164,"name":165,"slug":166,"color":167,"icon":168},6,"Databases","bases-de-donnees","bg-teal-500\u002F10 text-teal-400","database",[170],{"id":164,"name":165,"slug":166,"color":167,"icon":168},"\u002Fblog\u002Fcovers\u002Fheberger-redis-vps-poster.svg",{"categorySlug":173,"appSlug":174},"databases","redis-stack",{"id":176,"slug":177,"slugs":178,"title":182,"excerpt":183,"readTime":161,"views":18,"isPinned":19,"publishedAt":184,"category":185,"categories":190,"featuredImage":28,"bgImage":29,"posterImage":192,"relatedSolution":28},227,"caddy-traefik-or-nginx-proxy-manager-which-to-choose",{"fr":179,"en":177,"ar":180,"es":181},"choisir-reverse-proxy-vps-caddy-traefik-nginx","caddy-أم-traefik-أم-nginx-proxy-manager-أيهما-تختار","elegir-reverse-proxy-vps-caddy-traefik-nginx","Caddy, Traefik or Nginx Proxy Manager: which to choose?","Caddy, Traefik or Nginx Proxy Manager for your VPS? A practical comparison to choose the right reverse proxy for your Docker stack.","2026-08-06T00:00:00+00:00",{"id":186,"name":187,"slug":188,"color":189,"icon":188},5,"Comparison","comparatif","bg-info\u002F10 text-info",[191],{"id":186,"name":187,"slug":188,"color":189,"icon":188},"\u002Fblog\u002Fcovers\u002Fchoisir-reverse-proxy-vps-caddy-traefik-nginx-poster.svg",1789046145635]