{"id":3878,"date":"2026-01-01T14:44:45","date_gmt":"2026-01-01T11:44:45","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/server-side-core-web-vitals-tuning-for-better-ttfb-lcp-and-inp\/"},"modified":"2026-01-01T14:44:45","modified_gmt":"2026-01-01T11:44:45","slug":"server-side-core-web-vitals-tuning-for-better-ttfb-lcp-and-inp","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/server-side-core-web-vitals-tuning-for-better-ttfb-lcp-and-inp\/","title":{"rendered":"Server-Side Core Web Vitals Tuning for Better TTFB, LCP and INP"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><p>When teams talk about Core Web Vitals, the conversation usually starts with images, JavaScript bundles and design tweaks. But if your hosting and server settings are not tuned properly, you hit a ceiling very quickly: TTFB will not go below a certain point, LCP keeps jumping on first load, and INP spikes during traffic peaks. In this article we look at Core Web Vitals explicitly from the <strong>hosting side<\/strong>: which server settings, protocols and resource choices actually move the needle, and how you can implement them step by step on shared hosting, <a href=\"https:\/\/www.dchost.com\/vps\">VPS<\/a>, <a href=\"https:\/\/www.dchost.com\/dedicated-server\">dedicated server<\/a>s or colocation at dchost.com. We will focus on three metrics: <strong>TTFB<\/strong> (Time To First Byte), <strong>LCP<\/strong> (Largest Contentful Paint) and <strong>INP<\/strong> (Interaction to Next Paint). You will see how they connect to CPU, disk, PHP-FPM, TLS, caching and databases, and you will leave with a concrete checklist you can apply on your own servers.<\/p>\n<div id=\"toc_container\" class=\"toc_transparent no_bullets\"><p class=\"toc_title\">\u0130&ccedil;indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#Core_Web_Vitals_From_a_Server_Perspective\"><span class=\"toc_number toc_depth_1\">1<\/span> Core Web Vitals From a Server Perspective<\/a><ul><li><a href=\"#Quick_recap_of_TTFB_LCP_and_INP\"><span class=\"toc_number toc_depth_2\">1.1<\/span> Quick recap of TTFB, LCP and INP<\/a><\/li><li><a href=\"#What_is_actually_under_hosting_control\"><span class=\"toc_number toc_depth_2\">1.2<\/span> What is actually under hosting control?<\/a><\/li><\/ul><\/li><li><a href=\"#Measure_TTFB_LCP_and_INP_Correctly_Before_Tuning\"><span class=\"toc_number toc_depth_1\">2<\/span> Measure TTFB, LCP and INP Correctly Before Tuning<\/a><ul><li><a href=\"#Lab_vs_field_data_and_why_both_matter\"><span class=\"toc_number toc_depth_2\">2.1<\/span> Lab vs field data and why both matter<\/a><\/li><li><a href=\"#Isolating_the_server_component_of_TTFB\"><span class=\"toc_number toc_depth_2\">2.2<\/span> Isolating the server component of TTFB<\/a><\/li><li><a href=\"#Reading_LCP_and_INP_with_server_glasses_on\"><span class=\"toc_number toc_depth_2\">2.3<\/span> Reading LCP and INP with server glasses on<\/a><\/li><\/ul><\/li><li><a href=\"#Server_Settings_That_Directly_Reduce_TTFB\"><span class=\"toc_number toc_depth_1\">3<\/span> Server Settings That Directly Reduce TTFB<\/a><ul><li><a href=\"#1_Choose_fast_storage_CPU_and_the_right_location\"><span class=\"toc_number toc_depth_2\">3.1<\/span> 1. Choose fast storage, CPU and the right location<\/a><\/li><li><a href=\"#2_Use_modern_protocols_HTTP2_HTTP3_and_TLS_13\"><span class=\"toc_number toc_depth_2\">3.2<\/span> 2. Use modern protocols: HTTP\/2, HTTP\/3 and TLS 1.3<\/a><\/li><li><a href=\"#3_Tune_TLS_and_connection_settings\"><span class=\"toc_number toc_depth_2\">3.3<\/span> 3. Tune TLS and connection settings<\/a><\/li><li><a href=\"#4_PHP-FPM_and_OPcache_eliminating_cold_starts\"><span class=\"toc_number toc_depth_2\">3.4<\/span> 4. PHP-FPM and OPcache: eliminating cold starts<\/a><\/li><li><a href=\"#5_Server-side_caching_the_biggest_lever_for_dynamic_sites\"><span class=\"toc_number toc_depth_2\">3.5<\/span> 5. Server-side caching: the biggest lever for dynamic sites<\/a><\/li><li><a href=\"#6_Database_performance_hidden_TTFB_killer\"><span class=\"toc_number toc_depth_2\">3.6<\/span> 6. Database performance: hidden TTFB killer<\/a><\/li><\/ul><\/li><li><a href=\"#Hosting-Side_Optimizations_for_Better_LCP\"><span class=\"toc_number toc_depth_1\">4<\/span> Hosting-Side Optimizations for Better LCP<\/a><ul><li><a href=\"#1_Reduce_initial_HTML_delay_LCP_starts_with_TTFB\"><span class=\"toc_number toc_depth_2\">4.1<\/span> 1. Reduce initial HTML delay (LCP starts with TTFB)<\/a><\/li><li><a href=\"#2_Serve_images_efficiently_from_the_server\"><span class=\"toc_number toc_depth_2\">4.2<\/span> 2. Serve images efficiently from the server<\/a><\/li><li><a href=\"#3_Compression_BrotliGzip_for_HTML_CSS_and_JS\"><span class=\"toc_number toc_depth_2\">4.3<\/span> 3. Compression (Brotli\/Gzip) for HTML, CSS and JS<\/a><\/li><li><a href=\"#4_Cache-Control_and_ETag_faster_repeat_visits\"><span class=\"toc_number toc_depth_2\">4.4<\/span> 4. Cache-Control and ETag: faster repeat visits<\/a><\/li><li><a href=\"#5_Prioritizing_critical_resources_from_the_server\"><span class=\"toc_number toc_depth_2\">4.5<\/span> 5. Prioritizing critical resources from the server<\/a><\/li><\/ul><\/li><li><a href=\"#Reducing_INP_with_Faster_Backends_and_APIs\"><span class=\"toc_number toc_depth_1\">5<\/span> Reducing INP with Faster Backends and APIs<\/a><ul><li><a href=\"#1_Understand_when_INP_is_backend-limited\"><span class=\"toc_number toc_depth_2\">5.1<\/span> 1. Understand when INP is backend-limited<\/a><\/li><li><a href=\"#2_Optimize_API_and_AJAX_endpoints_on_the_server\"><span class=\"toc_number toc_depth_2\">5.2<\/span> 2. Optimize API and AJAX endpoints on the server<\/a><\/li><li><a href=\"#3_Keep_PHP_and_database_warm_under_load\"><span class=\"toc_number toc_depth_2\">5.3<\/span> 3. Keep PHP and database warm under load<\/a><\/li><li><a href=\"#4_Real-time_updates_done_right\"><span class=\"toc_number toc_depth_2\">5.4<\/span> 4. Real-time updates done right<\/a><\/li><\/ul><\/li><li><a href=\"#Concrete_Configuration_Patterns_on_Popular_Web_Servers\"><span class=\"toc_number toc_depth_1\">6<\/span> Concrete Configuration Patterns on Popular Web Servers<\/a><ul><li><a href=\"#Nginx\"><span class=\"toc_number toc_depth_2\">6.1<\/span> Nginx<\/a><\/li><li><a href=\"#Apache_prefork_worker_event\"><span class=\"toc_number toc_depth_2\">6.2<\/span> Apache (prefork, worker, event)<\/a><\/li><li><a href=\"#LiteSpeed_OpenLiteSpeed\"><span class=\"toc_number toc_depth_2\">6.3<\/span> LiteSpeed \/ OpenLiteSpeed<\/a><\/li><li><a href=\"#PHP_versions_and_extensions\"><span class=\"toc_number toc_depth_2\">6.4<\/span> PHP versions and extensions<\/a><\/li><\/ul><\/li><li><a href=\"#When_to_Scale_Up_or_Change_Your_Hosting_Plan\"><span class=\"toc_number toc_depth_1\">7<\/span> When to Scale Up or Change Your Hosting Plan<\/a><ul><li><a href=\"#Recognizing_when_tuning_is_not_enough\"><span class=\"toc_number toc_depth_2\">7.1<\/span> Recognizing when tuning is not enough<\/a><\/li><li><a href=\"#How_dchostcom_fits_into_this_picture\"><span class=\"toc_number toc_depth_2\">7.2<\/span> How dchost.com fits into this picture<\/a><\/li><\/ul><\/li><li><a href=\"#Turning_Core_Web_Vitals_into_a_Hosting_Checklist\"><span class=\"toc_number toc_depth_1\">8<\/span> Turning Core Web Vitals into a Hosting Checklist<\/a><\/li><\/ul><\/div>\n<h2><span id=\"Core_Web_Vitals_From_a_Server_Perspective\">Core Web Vitals From a Server Perspective<\/span><\/h2>\n<h3><span id=\"Quick_recap_of_TTFB_LCP_and_INP\">Quick recap of TTFB, LCP and INP<\/span><\/h3>\n<p>Google\u2019s Core Web Vitals are user-centric metrics, but they are heavily influenced by how your hosting stack behaves.<\/p>\n<ul>\n<li><strong>TTFB (Time To First Byte)<\/strong>: The time between the browser requesting a page and receiving the first byte of the HTML. This is the metric most directly tied to your server and hosting configuration.<\/li>\n<li><strong>LCP (Largest Contentful Paint)<\/strong>: When the main visible content (often a hero image, headline or large block) appears. LCP is part frontend (images, CSS) and part backend (how fast HTML and critical resources are delivered).<\/li>\n<li><strong>INP (Interaction to Next Paint)<\/strong>: Measures how quickly the page reacts visually after user interactions (clicks, taps, key presses). JavaScript is a big factor, but backend response time for APIs and forms matters a lot, especially on dynamic sites and dashboards.<\/li>\n<\/ul>\n<p>Think of it this way: <strong>fast servers shrink the \u201cbackend\u201d piece<\/strong> of each metric. If your PHP, database and network are slow, no amount of image compression will fully fix your scores.<\/p>\n<h3><span id=\"What_is_actually_under_hosting_control\">What is actually under hosting control?<\/span><\/h3>\n<p>From the hosting side we can influence:<\/p>\n<ul>\n<li>Physical and virtual resources (CPU, RAM, NVMe vs SATA, network latency).<\/li>\n<li>Web server and PHP engine (Apache, Nginx, LiteSpeed, PHP-FPM, OPcache).<\/li>\n<li>TLS, HTTP versions and TCP tuning.<\/li>\n<li>Server-side caching and database performance.<\/li>\n<li>How static assets and images are compressed and cached.<\/li>\n<\/ul>\n<p>In another article we explained the big picture in <a href=\"https:\/\/www.dchost.com\/blog\/en\/core-web-vitals-ve-hosting-altyapisi-ttfb-lcp-ve-clsyi-sunucu-tarafinda-iyilestirme-rehberi\/\">how Core Web Vitals and hosting architecture are connected<\/a>. Here we go deeper into concrete configuration changes you can apply.<\/p>\n<h2><span id=\"Measure_TTFB_LCP_and_INP_Correctly_Before_Tuning\">Measure TTFB, LCP and INP Correctly Before Tuning<\/span><\/h2>\n<h3><span id=\"Lab_vs_field_data_and_why_both_matter\">Lab vs field data and why both matter<\/span><\/h3>\n<p>Before touching your server, make sure you are reading the metrics correctly:<\/p>\n<ul>\n<li><strong>Lab data<\/strong> from tools like Lighthouse, WebPageTest or GTmetrix show how your site performs in a controlled environment.<\/li>\n<li><strong>Field data<\/strong> from Chrome User Experience Report (CrUX) and Search Console\u2019s \u201cCore Web Vitals\u201d report reflect real users across devices, locations and networks.<\/li>\n<\/ul>\n<p>Lab tools are perfect to see the impact of a specific server tweak. Field data tells you whether your changes actually helped your user base over time.<\/p>\n<h3><span id=\"Isolating_the_server_component_of_TTFB\">Isolating the server component of TTFB<\/span><\/h3>\n<p>To evaluate hosting-side impact you need to separate server work from frontend work:<\/p>\n<ol>\n<li><strong>Test a simple static HTML file<\/strong> on the same domain (for example <code>\/ttfb-test.html<\/code>). If this file has high TTFB, the bottleneck is likely network, TLS or web server \u2013 not your application.<\/li>\n<li><strong>Then test your dynamic homepage<\/strong> (WordPress, Laravel, Magento, etc.). The difference between static and dynamic TTFB shows how much time is spent in PHP, database and application logic.<\/li>\n<li><strong>Test with and without cache<\/strong> (if you use full-page caching). This highlights how much uncached requests cost.<\/li>\n<\/ol>\n<p>For a methodical approach to tools and test locations, check our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/web-sitenizin-hizini-dogru-olcmek-gtmetrix-pagespeed-insights-ve-webpagetest-rehberi\/\">how to properly test your website speed with GTmetrix, PageSpeed Insights and WebPageTest<\/a>.<\/p>\n<h3><span id=\"Reading_LCP_and_INP_with_server_glasses_on\">Reading LCP and INP with server glasses on<\/span><\/h3>\n<p>For LCP and INP, pay attention to two specific views:<\/p>\n<ul>\n<li><strong>\u201cDiagnostics\u201d and \u201cOpportunities\u201d sections<\/strong> in Lighthouse and PageSpeed Insights: look for \u201cReduce initial server response time\u201d, \u201cReduce JavaScript execution time\u201d, \u201cEliminate render-blocking resources\u201d and \u201cReduce main-thread work\u201d.<\/li>\n<li><strong>Network waterfalls<\/strong>: see if the LCP resource (often an image or background) is delayed because HTML arrives late, DNS\/TLS takes too long, or the image is huge and uncompressed.<\/li>\n<\/ul>\n<p>For INP, look at the timing breakdown: if interactions trigger API calls or form submissions that take 500\u2013800 ms to respond, server tuning can have a major effect.<\/p>\n<h2><span id=\"Server_Settings_That_Directly_Reduce_TTFB\">Server Settings That Directly Reduce TTFB<\/span><\/h2>\n<h3><span id=\"1_Choose_fast_storage_CPU_and_the_right_location\">1. Choose fast storage, CPU and the right location<\/span><\/h3>\n<p>Hardware is the foundation. If your database and PHP run on slow disks or saturated CPUs, configuration tweaks only help so much.<\/p>\n<ul>\n<li><strong>Storage<\/strong>: Prefer NVMe SSDs over classic SATA SSDs or HDD for your main web and database workload. NVMe brings much higher IOPS and lower latency, which translates to faster queries and PHP file loads. We explained these differences in detail in our <a href=\"https:\/\/www.dchost.com\/blog\/en\/nvme-ssd-sata-ssd-ve-hdd-karsilastirmasi-web-hosting-yedek-ve-arsiv-icin-dogru-disk-secimi\/\">NVMe SSD vs SATA SSD vs HDD comparison for hosting<\/a>.<\/li>\n<li><strong>CPU<\/strong>: Dynamic sites (WordPress, WooCommerce, Laravel, Magento, etc.) benefit from higher per-core performance. If single request CPU time is high, consider plans with stronger per-core performance or more vCPUs.<\/li>\n<li><strong>Server location<\/strong>: Hosting physically closer to your main audience reduces network round-trip time and DNS\/TLS latency. Our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/sunucu-lokasyonu-seoyu-etkiler-mi-en-dogru-hosting-bolgesini-secme-rehberi\/\">how server location affects SEO and speed<\/a> gives practical examples.<\/li>\n<\/ul>\n<h3><span id=\"2_Use_modern_protocols_HTTP2_HTTP3_and_TLS_13\">2. Use modern protocols: HTTP\/2, HTTP\/3 and TLS 1.3<\/span><\/h3>\n<p>Protocol-level upgrades are low-hanging fruit:<\/p>\n<ul>\n<li><strong>Enable HTTP\/2<\/strong> on your web server or control panel. It allows multiplexing (multiple requests over a single connection) and header compression, reducing overhead.<\/li>\n<li><strong>Enable HTTP\/3 (QUIC)<\/strong> where supported. It can significantly improve performance on lossy mobile networks thanks to faster recovery and connection establishment.<\/li>\n<li><strong>Use TLS 1.3<\/strong> for HTTPS. It reduces handshake round trips, helping first-time visitors and cold connections.<\/li>\n<\/ul>\n<p>For configuration details and SEO impact, see our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/http-2-ve-http-3-destegi-seo-ve-core-web-vitalsi-nasil-etkiler-hosting-secerken-nelere-bakmali\/\">how HTTP\/2 and HTTP\/3 support affects SEO and Core Web Vitals when you choose hosting<\/a>.<\/p>\n<h3><span id=\"3_Tune_TLS_and_connection_settings\">3. Tune TLS and connection settings<\/span><\/h3>\n<p>TLS security is non-negotiable, but we can configure it without slowing things down:<\/p>\n<ul>\n<li><strong>Enable OCSP stapling<\/strong> so browsers do not need to contact certificate authorities directly.<\/li>\n<li><strong>Use session resumption<\/strong> to speed up repeat connections.<\/li>\n<li>Keep <strong>keep-alive<\/strong> enabled and set a reasonable timeout (for example 30\u201360 seconds) to reuse connections between page resources.<\/li>\n<\/ul>\n<p>On Nginx, settings like <code>keepalive_timeout<\/code>, <code>keepalive_requests<\/code>, and tuned <code>worker_connections<\/code> make sure the server can handle many concurrent clients without queuing.<\/p>\n<h3><span id=\"4_PHP-FPM_and_OPcache_eliminating_cold_starts\">4. PHP-FPM and OPcache: eliminating cold starts<\/span><\/h3>\n<p>Most PHP-based sites suffer from slow TTFB during traffic spikes because PHP workers are not tuned for the real workload. Key areas:<\/p>\n<ul>\n<li><strong>Process manager (<code>pm<\/code>) mode<\/strong>: For most production workloads, <code>pm = dynamic<\/code> or <code>pm = static<\/code> behaves better than <code>ondemand<\/code>, which introduces cold start latency.<\/li>\n<li><strong>Worker counts<\/strong>: <code>pm.max_children<\/code> should be high enough that PHP workers do not queue but low enough not to exhaust RAM. We covered calculations step by step in <a href=\"https:\/\/www.dchost.com\/blog\/en\/wordpress-ve-woocommerce-icin-php-fpm-ayarlari-pm-pm-max_children-ve-pm-max_requests-hesaplama-rehberi\/\">our PHP-FPM settings guide for WordPress and WooCommerce<\/a>.<\/li>\n<li><strong>max_requests<\/strong>: Reset workers after a reasonable number of requests (e.g. 500\u20132000) to avoid memory leaks without constantly recycling.<\/li>\n<li><strong>OPcache<\/strong>: Enable and tune PHP OPcache so scripts are compiled once and served from memory. For WordPress, Laravel and WooCommerce we shared recommended values in our <a href=\"https:\/\/www.dchost.com\/blog\/en\/php-opcache-ayarlari-wordpress-laravel-ve-woocommerce-icin-en-iyi-konfigurasyon-rehberi\/\">PHP OPcache configuration article<\/a>.<\/li>\n<\/ul>\n<p>When OPcache and PHP-FPM are set properly, TTFB for cached pages often drops below 100\u2013200 ms on a well-sized VPS or dedicated server.<\/p>\n<h3><span id=\"5_Server-side_caching_the_biggest_lever_for_dynamic_sites\">5. Server-side caching: the biggest lever for dynamic sites<\/span><\/h3>\n<p>For most content sites and stores, the single most effective way to lower TTFB is <strong>full-page caching<\/strong> of HTML:<\/p>\n<ul>\n<li><strong>Nginx FastCGI cache or microcaching<\/strong> in front of PHP can serve pages from memory or disk in a few milliseconds, while only uncached requests hit PHP and MySQL. We walked through this concept in <a href=\"https:\/\/www.dchost.com\/blog\/en\/nginx-mikro-onbellekleme-ile-php-uygulamalarini-ucurmak-1-5-sn-cache-bypass-ve-purge-ne-zaman-nasil\/\">our Nginx microcaching article<\/a>.<\/li>\n<li><strong>LiteSpeed Cache<\/strong> or Varnish-based setups can also deliver full HTML extremely fast with proper cache rules.<\/li>\n<li><strong>Object cache<\/strong> with Redis or Memcached reduces database load and speeds up uncached requests. See our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/wordpresste-redis-memcached-object-cache-kurulumu\/\">setting up WordPress object cache with Redis or Memcached<\/a>.<\/li>\n<\/ul>\n<p>Important: combine full-page caching with precise cache bypass and purge rules for carts, checkouts and personalized dashboards so functionality stays correct while TTFB remains low for the majority of pages.<\/p>\n<h3><span id=\"6_Database_performance_hidden_TTFB_killer\">6. Database performance: hidden TTFB killer<\/span><\/h3>\n<p>If your TTFB is high only on specific pages (product listings, reports, searches), the bottleneck is often the database:<\/p>\n<ul>\n<li>Ensure <strong>proper indexing<\/strong> on frequently queried columns.<\/li>\n<li>Increase <strong>buffer pool size<\/strong> for InnoDB so hot data stays in memory.<\/li>\n<li>Optimize slow queries using <code>EXPLAIN<\/code> and slow query logs.<\/li>\n<\/ul>\n<p>For WooCommerce and large catalogs we prepared a deep dive in our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/woocommerce-ve-buyuk-katalog-siteleri-icin-mysql-indeksleme-ve-sorgu-optimizasyonu-rehberi\/\">MySQL indexing and query optimization<\/a>, which is directly applicable to lowering TTFB on heavy pages.<\/p>\n<h2><span id=\"Hosting-Side_Optimizations_for_Better_LCP\">Hosting-Side Optimizations for Better LCP<\/span><\/h2>\n<h3><span id=\"1_Reduce_initial_HTML_delay_LCP_starts_with_TTFB\">1. Reduce initial HTML delay (LCP starts with TTFB)<\/span><\/h3>\n<p>LCP cannot be good if the initial HTML document is slow. Everything in the previous section on TTFB directly benefits LCP, especially for first visits and landing pages. Focus on:<\/p>\n<ul>\n<li>Keeping <strong>TTFB under ~200 ms<\/strong> for your HTML on a typical connection.<\/li>\n<li>Serving HTML via HTTP\/2\/3 and TLS 1.3.<\/li>\n<li>Minimizing heavy queries and server-side rendering work for the above-the-fold content.<\/li>\n<\/ul>\n<h3><span id=\"2_Serve_images_efficiently_from_the_server\">2. Serve images efficiently from the server<\/span><\/h3>\n<p>The LCP element is often a hero image or large background. Hosting-side settings can make a huge difference:<\/p>\n<ul>\n<li><strong>Image formats<\/strong>: Enable WebP and, where appropriate, AVIF generation and delivery. This can be done via image optimization plugins, build pipelines or server-side tools.<\/li>\n<li><strong>Responsive sizes<\/strong>: Serve different sizes via <code>srcset<\/code> and ensure your server or CDN caches them efficiently.<\/li>\n<li><strong>CDN and caching<\/strong>: Put heavy images behind a CDN with proper cache headers and regional PoPs close to users.<\/li>\n<\/ul>\n<p>We explored this topic in detail in our piece on <a href=\"https:\/\/www.dchost.com\/blog\/en\/gorsel-seo-ve-hosting-altyapisi-webp-avif-cdn-alt-alan-adlari-ve-gorsel-site-haritasi\/\">image SEO and hosting infrastructure with WebP\/AVIF and CDNs<\/a>. Many of those best practices directly improve LCP.<\/p>\n<h3><span id=\"3_Compression_BrotliGzip_for_HTML_CSS_and_JS\">3. Compression (Brotli\/Gzip) for HTML, CSS and JS<\/span><\/h3>\n<p>Compressed responses travel faster, especially over slower connections. On the server you should:<\/p>\n<ul>\n<li>Enable <strong>Gzip<\/strong> or (preferably) <strong>Brotli<\/strong> compression for HTML, CSS, JavaScript, JSON and SVG.<\/li>\n<li>Exclude already-compressed formats like JPEG, PNG, WebP and PDFs.<\/li>\n<li>Use balanced compression levels (e.g. Brotli 4\u20136) to avoid high CPU usage.<\/li>\n<\/ul>\n<p>For Nginx, Apache and LiteSpeed examples, see our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/brotli-ve-gzip-sikistirma-ayarlari-nginx-apache-ve-litespeedde-core-web-vitals-icin-dogru-konfigurasyon\/\">Brotli and Gzip compression settings for faster Core Web Vitals<\/a>.<\/p>\n<h3><span id=\"4_Cache-Control_and_ETag_faster_repeat_visits\">4. Cache-Control and ETag: faster repeat visits<\/span><\/h3>\n<p>LCP is measured not only on first visits but also on returning users. Correct cache headers from the server allow browsers and CDNs to reuse assets efficiently:<\/p>\n<ul>\n<li>Set <strong>long-lived <code>Cache-Control<\/code><\/strong> for static assets (CSS, JS, fonts, images) with file name versioning.<\/li>\n<li>Use <strong>ETag<\/strong> or <strong>Last-Modified<\/strong> headers so browsers can validate assets cheaply.<\/li>\n<li>For HTML, use short TTLs or no cache unless you have a clear full-page caching strategy.<\/li>\n<\/ul>\n<p>We explained practical patterns in our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/tarayici-ve-cdn-onbellekleme-neden-bu-kadar-kritik\/\">why HTTP Cache-Control, ETag and CDN rules are so critical<\/a> for performance. Applying these correctly reduces network work on subsequent page views and improves LCP for returning visitors.<\/p>\n<h3><span id=\"5_Prioritizing_critical_resources_from_the_server\">5. Prioritizing critical resources from the server<\/span><\/h3>\n<p>Your hosting configuration can hint which assets are crucial for LCP:<\/p>\n<ul>\n<li>Use <strong><code>link rel=\"preload\"<\/code><\/strong> headers for critical CSS, fonts and key hero images so browsers fetch them early.<\/li>\n<li>Serve a <strong>small, render-ready CSS bundle<\/strong> instead of many tiny files. Combining and minifying CSS can be done at build time; the server just needs to cache and deliver it quickly.<\/li>\n<li>Avoid server-side redirects (<code>301\/302<\/code>) before the final HTML whenever possible; each redirect adds extra RTTs before the browser can fetch LCP resources.<\/li>\n<\/ul>\n<h2><span id=\"Reducing_INP_with_Faster_Backends_and_APIs\">Reducing INP with Faster Backends and APIs<\/span><\/h2>\n<h3><span id=\"1_Understand_when_INP_is_backend-limited\">1. Understand when INP is backend-limited<\/span><\/h3>\n<p>INP is often framed as a JavaScript problem, but many real-world interactions depend heavily on backend speed:<\/p>\n<ul>\n<li>Clicking \u201cAdd to cart\u201d or \u201cPlace order\u201d triggers PHP and database work.<\/li>\n<li>Searching, filtering and pagination are often driven by synchronous API calls.<\/li>\n<li>Dashboards and admin panels hit multiple endpoints when you interact with them.<\/li>\n<\/ul>\n<p>If those endpoints respond in 800\u20131200 ms, the browser cannot update the UI smoothly, and INP suffers even if your JavaScript is well-written.<\/p>\n<h3><span id=\"2_Optimize_API_and_AJAX_endpoints_on_the_server\">2. Optimize API and AJAX endpoints on the server<\/span><\/h3>\n<p>Focus on the endpoints tied to key user actions:<\/p>\n<ul>\n<li><strong>Profile and cache<\/strong> expensive database queries via Redis or other caches.<\/li>\n<li>Return <strong>only the data needed<\/strong> for the current interaction instead of heavy payloads.<\/li>\n<li>Use <strong>asynchronous queues<\/strong> (Laravel queues, WordPress background processing, cron jobs) for slow tasks like sending emails, generating PDFs or syncing inventory, instead of doing them inline with the user request.<\/li>\n<li>Keep <strong>PHP max_execution_time<\/strong> reasonable (e.g. 60\u2013120 seconds for edge cases) but aim for normal interactions to return within 200\u2013400 ms server time.<\/li>\n<\/ul>\n<h3><span id=\"3_Keep_PHP_and_database_warm_under_load\">3. Keep PHP and database warm under load<\/span><\/h3>\n<p>INP often deteriorates during traffic peaks because servers start queuing requests:<\/p>\n<ul>\n<li>Ensure <strong>PHP-FPM workers<\/strong> can handle your concurrency without reaching <code>max_children<\/code> limits.<\/li>\n<li>Configure <strong>database connection pools<\/strong> or persistent connections where appropriate to avoid connection setup overhead.<\/li>\n<li>Monitor CPU, RAM and disk IO to make sure your plan is not saturated. Our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/hosting-paketinizi-yukseltmeniz-gerektigini-gosteren-9-sunucu-tarafli-sinyal\/\">server-side signals that it is time to upgrade your hosting plan<\/a> helps you interpret these symptoms.<\/li>\n<\/ul>\n<h3><span id=\"4_Real-time_updates_done_right\">4. Real-time updates done right<\/span><\/h3>\n<p>For applications with intense interaction (trading dashboards, chat, live notifications), traditional polling can damage INP because every UI action causes a full HTTP round trip. In such cases, hosting support for <strong>WebSockets<\/strong> or similar real-time channels helps you maintain a responsive UI with fewer heavy requests.<\/p>\n<p>We explained how these workloads behave on different hosting types in our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/websocket-tabanli-gercek-zamanli-uygulamalar-icin-dogru-hosting-secimi\/\">how WebSockets and real-time apps really work and how to host them<\/a>.<\/p>\n<h2><span id=\"Concrete_Configuration_Patterns_on_Popular_Web_Servers\">Concrete Configuration Patterns on Popular Web Servers<\/span><\/h2>\n<h3><span id=\"Nginx\">Nginx<\/span><\/h3>\n<p>Nginx is often used as a reverse proxy and static file server in front of PHP-FPM:<\/p>\n<ul>\n<li><strong>Worker processes and connections<\/strong>: Set <code>worker_processes auto;<\/code> and align <code>worker_connections<\/code> with expected concurrency.<\/li>\n<li><strong>FastCGI tuning<\/strong>: Use <code>fastcgi_keep_conn on;<\/code>, set readable timeouts (not too low to cause 502 errors, not too high to leave hanging connections), and ensure <code>fastcgi_buffers<\/code> are adequate.<\/li>\n<li><strong>Static file delivery<\/strong>: Serve images, CSS and JS directly from Nginx with proper <code>expires<\/code> and <code>Cache-Control<\/code> headers.<\/li>\n<li><strong>Microcaching<\/strong>: A short 1\u20135 second cache can dramatically reduce backend load during spikes while still staying fresh for most users.<\/li>\n<\/ul>\n<h3><span id=\"Apache_prefork_worker_event\">Apache (prefork, worker, event)<\/span><\/h3>\n<p>Apache performance heavily depends on the MPM (Multi-Processing Module):<\/p>\n<ul>\n<li><strong>Use <code>event<\/code> or <code>worker<\/code> MPM<\/strong> instead of <code>prefork<\/code> when possible, especially with PHP-FPM, to handle more concurrent requests with less RAM.<\/li>\n<li>Tune <strong><code>ServerLimit<\/code>, <code>MaxRequestWorkers<\/code>, <code>MaxConnectionsPerChild<\/code><\/strong> to match your hardware capacity and concurrency needs.<\/li>\n<li>Enable and tune <strong>mod_deflate<\/strong> or <strong>mod_brotli<\/strong> for compression and <strong>mod_http2<\/strong> for HTTP\/2.<\/li>\n<\/ul>\n<p>On shared hosting at dchost.com, many of these are pre-tuned, but on VPS\/dedicated\/colocation you have full control.<\/p>\n<h3><span id=\"LiteSpeed_OpenLiteSpeed\">LiteSpeed \/ OpenLiteSpeed<\/span><\/h3>\n<p>LiteSpeed integrates tightly with PHP and has built-in full-page caching:<\/p>\n<ul>\n<li>Enable <strong>LSCache<\/strong> and configure cache rules cautiously around e-commerce carts, checkouts and personalized content.<\/li>\n<li>Use <strong>Brotli<\/strong> compression and HTTP\/3 support built into the server.<\/li>\n<li>Adjust <strong>Max Connections<\/strong> and PHP LSAPI worker settings according to your concurrency and RAM.<\/li>\n<\/ul>\n<p>Many WordPress and WooCommerce sites see dramatic TTFB and LCP improvements with LiteSpeed-based hosting when cache and PHP workers are configured correctly.<\/p>\n<h3><span id=\"PHP_versions_and_extensions\">PHP versions and extensions<\/span><\/h3>\n<p>Beyond FPM pool tuning, the choice of PHP version and modules matters:<\/p>\n<ul>\n<li><strong>Use recent stable PHP 8.x versions<\/strong> for significant performance gains compared to older 7.x releases.<\/li>\n<li>Disable unused extensions and modules to reduce startup overhead.<\/li>\n<li>Keep an eye on compatibility when upgrading; test in staging first.<\/li>\n<\/ul>\n<h2><span id=\"When_to_Scale_Up_or_Change_Your_Hosting_Plan\">When to Scale Up or Change Your Hosting Plan<\/span><\/h2>\n<h3><span id=\"Recognizing_when_tuning_is_not_enough\">Recognizing when tuning is not enough<\/span><\/h3>\n<p>There is a point where even the best-tuned server cannot hide the fact that you have outgrown your plan. Typical signs:<\/p>\n<ul>\n<li>CPU usage hitting 80\u2013100% during normal traffic, causing TTFB spikes and unstable INP.<\/li>\n<li>High IOwait (disk bottlenecks) despite query and cache optimizations.<\/li>\n<li>PHP-FPM and database connections frequently reaching their limits.<\/li>\n<li>Core Web Vitals significantly worse during campaigns or peak hours even with proper caching.<\/li>\n<\/ul>\n<p>At that stage, consider moving from shared hosting to a VPS, from a small VPS to a larger one, or to a dedicated server or colocation depending on your growth plans and budgets. The good news is that if you have already applied the tuning in this article, the migration mostly becomes a resource scaling exercise rather than a full redesign.<\/p>\n<h3><span id=\"How_dchostcom_fits_into_this_picture\">How dchost.com fits into this picture<\/span><\/h3>\n<p>Because dchost.com offers shared hosting, VPS, dedicated servers and colocation, we see the full spectrum from small blogs to high-traffic e-commerce and SaaS projects. In practice, we often recommend this path:<\/p>\n<ul>\n<li><strong>Start on a well-configured shared or managed plan<\/strong> if you have low to medium traffic and do not want to manage the OS layer.<\/li>\n<li><strong>Move to a VPS<\/strong> when you need custom PHP, database or caching configurations to push Core Web Vitals further.<\/li>\n<li><strong>Upgrade to dedicated or colocation<\/strong> when you need guaranteed CPU, large RAM and storage, or custom network\/security layouts.<\/li>\n<\/ul>\n<p>In every step, you can carry over the same principles: fast storage, modern protocols, tuned PHP-FPM and database, aggressive but safe caching, and solid monitoring.<\/p>\n<h2><span id=\"Turning_Core_Web_Vitals_into_a_Hosting_Checklist\">Turning Core Web Vitals into a Hosting Checklist<\/span><\/h2>\n<p>Improving Core Web Vitals is not just a frontend exercise. From the hosting side, you can dramatically reduce TTFB, stabilize LCP and prevent INP regressions by treating your server like a tuned application component instead of a black box. Start by measuring TTFB on both static and dynamic pages, then apply the layers covered here: NVMe storage, right-sized CPU and RAM, HTTP\/2\/3 and TLS 1.3, PHP-FPM and OPcache tuning, full-page and object caching, compression and cache headers, and optimized databases and APIs. If you are battling stubborn TTFB issues, our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/yuksek-ttfb-sorununu-cozmek-wordpress-ve-php-sitelerde-sunucu-tarafli-nedenler-ve-cozumler\/\">server-side causes and solutions for high TTFB<\/a> is a good companion to this guide.<\/p>\n<p>If you are hosting with dchost.com and want to push your Core Web Vitals further, our team can help you review your current plan, PHP-FPM pools, caching layer and database settings, and suggest a realistic roadmap: small configuration changes where possible, or a move to a better-suited VPS or dedicated server when necessary. The important part is to approach Core Web Vitals as a joint effort between frontend and hosting. When both layers are aligned, your pages feel instantly faster, users stay longer, and search engines see the stability and speed you have worked hard to achieve.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>When teams talk about Core Web Vitals, the conversation usually starts with images, JavaScript bundles and design tweaks. But if your hosting and server settings are not tuned properly, you hit a ceiling very quickly: TTFB will not go below a certain point, LCP keeps jumping on first load, and INP spikes during traffic peaks. [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":3879,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-3878","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-teknoloji"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/3878","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=3878"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/3878\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/3879"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=3878"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=3878"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=3878"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}