{"id":3619,"date":"2025-12-28T21:27:36","date_gmt":"2025-12-28T18:27:36","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/brotli-and-gzip-compression-settings-for-faster-core-web-vitals\/"},"modified":"2025-12-28T21:27:36","modified_gmt":"2025-12-28T18:27:36","slug":"brotli-and-gzip-compression-settings-for-faster-core-web-vitals","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/brotli-and-gzip-compression-settings-for-faster-core-web-vitals\/","title":{"rendered":"Brotli and Gzip Compression Settings for Faster Core Web Vitals"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><p>When we review slow sites on our infrastructure at dchost.com, one pattern appears again and again: HTML, CSS and JavaScript are being sent completely uncompressed or with poorly tuned settings. Core Web Vitals like LCP and TTFB suffer, even though the server itself is not overloaded. The quickest win in many of these audits is simply configuring <strong>Brotli and Gzip compression settings<\/strong> correctly on Nginx, Apache or LiteSpeed.<\/p>\n<p>In this article, we will focus on practical, real-world tuning. We will look at how compression affects Core Web Vitals, when Brotli is better than Gzip (and when it is not), and how to configure each major web server so that you get maximum benefit without burning CPU. All examples are written from the perspective of running real production workloads on shared hosting, <a href=\"https:\/\/www.dchost.com\/vps\">VPS<\/a>, <a href=\"https:\/\/www.dchost.com\/dedicated-server\">dedicated server<\/a>s and even colocation environments, just like we do every day at dchost.com.<\/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=\"#How_Compression_Affects_Core_Web_Vitals\"><span class=\"toc_number toc_depth_1\">1<\/span> How Compression Affects Core Web Vitals<\/a><\/li><li><a href=\"#Brotli_vs_Gzip_What_You_Really_Need_to_Know\"><span class=\"toc_number toc_depth_1\">2<\/span> Brotli vs Gzip: What You Really Need to Know<\/a><ul><li><a href=\"#Compression_efficiency_and_CPU_cost\"><span class=\"toc_number toc_depth_2\">2.1<\/span> Compression efficiency and CPU cost<\/a><\/li><li><a href=\"#Browser_support_and_HTTPS_requirement\"><span class=\"toc_number toc_depth_2\">2.2<\/span> Browser support and HTTPS requirement<\/a><\/li><li><a href=\"#What_to_compress_and_what_not_to\"><span class=\"toc_number toc_depth_2\">2.3<\/span> What to compress (and what not to)<\/a><\/li><\/ul><\/li><li><a href=\"#Tuning_Brotli_and_Gzip_on_Nginx\"><span class=\"toc_number toc_depth_1\">3<\/span> Tuning Brotli and Gzip on Nginx<\/a><ul><li><a href=\"#Step_1_Enable_modules\"><span class=\"toc_number toc_depth_2\">3.1<\/span> Step 1: Enable modules<\/a><\/li><li><a href=\"#Step_2_Baseline_Gzip_settings\"><span class=\"toc_number toc_depth_2\">3.2<\/span> Step 2: Baseline Gzip settings<\/a><\/li><li><a href=\"#Step_3_Brotli_settings_for_dynamic_responses\"><span class=\"toc_number toc_depth_2\">3.3<\/span> Step 3: Brotli settings for dynamic responses<\/a><\/li><li><a href=\"#Step_4_Precompressed_static_assets\"><span class=\"toc_number toc_depth_2\">3.4<\/span> Step 4: Precompressed static assets<\/a><\/li><li><a href=\"#Step_5_Testing_Nginx_compression\"><span class=\"toc_number toc_depth_2\">3.5<\/span> Step 5: Testing Nginx compression<\/a><\/li><\/ul><\/li><li><a href=\"#Tuning_Brotli_and_Gzip_on_Apache_mod_deflate_mod_brotli\"><span class=\"toc_number toc_depth_1\">4<\/span> Tuning Brotli and Gzip on Apache (mod_deflate, mod_brotli)<\/a><ul><li><a href=\"#Step_1_Enable_the_modules\"><span class=\"toc_number toc_depth_2\">4.1<\/span> Step 1: Enable the modules<\/a><\/li><li><a href=\"#Step_2_Gzip_mod_deflate_configuration\"><span class=\"toc_number toc_depth_2\">4.2<\/span> Step 2: Gzip (mod_deflate) configuration<\/a><\/li><li><a href=\"#Step_3_Brotli_mod_brotli_configuration\"><span class=\"toc_number toc_depth_2\">4.3<\/span> Step 3: Brotli (mod_brotli) configuration<\/a><\/li><li><a href=\"#Step_4_htaccess_example\"><span class=\"toc_number toc_depth_2\">4.4<\/span> Step 4: .htaccess example<\/a><\/li><li><a href=\"#Step_5_Testing_Apache_compression\"><span class=\"toc_number toc_depth_2\">4.5<\/span> Step 5: Testing Apache compression<\/a><\/li><\/ul><\/li><li><a href=\"#Brotli_and_Gzip_on_LiteSpeedOpenLiteSpeed\"><span class=\"toc_number toc_depth_1\">5<\/span> Brotli and Gzip on LiteSpeed\/OpenLiteSpeed<\/a><ul><li><a href=\"#Server-level_compression_settings\"><span class=\"toc_number toc_depth_2\">5.1<\/span> Server-level compression settings<\/a><\/li><li><a href=\"#Virtual_host_and_context_overrides\"><span class=\"toc_number toc_depth_2\">5.2<\/span> Virtual host and context overrides<\/a><\/li><li><a href=\"#LiteSpeed_Cache_plugin_WordPress\"><span class=\"toc_number toc_depth_2\">5.3<\/span> LiteSpeed Cache plugin (WordPress)<\/a><\/li><\/ul><\/li><li><a href=\"#Practical_Tuning_Strategy_Across_All_Web_Servers\"><span class=\"toc_number toc_depth_1\">6<\/span> Practical Tuning Strategy Across All Web Servers<\/a><ul><li><a href=\"#1_Prioritize_the_right_content_types\"><span class=\"toc_number toc_depth_2\">6.1<\/span> 1. Prioritize the right content types<\/a><\/li><li><a href=\"#2_Choose_safe_compression_levels\"><span class=\"toc_number toc_depth_2\">6.2<\/span> 2. Choose safe compression levels<\/a><\/li><li><a href=\"#3_Align_compression_with_caching_and_CDN_strategy\"><span class=\"toc_number toc_depth_2\">6.3<\/span> 3. Align compression with caching and CDN strategy<\/a><\/li><li><a href=\"#4_Sync_with_TLS_and_HTTP_protocol_tuning\"><span class=\"toc_number toc_depth_2\">6.4<\/span> 4. Sync with TLS and HTTP protocol tuning<\/a><\/li><li><a href=\"#5_Measure_impact_on_Core_Web_Vitals_not_just_transfer_size\"><span class=\"toc_number toc_depth_2\">6.5<\/span> 5. Measure impact on Core Web Vitals, not just transfer size<\/a><\/li><\/ul><\/li><li><a href=\"#Choosing_the_Right_Hosting_Base_for_Brotli_and_Gzip\"><span class=\"toc_number toc_depth_1\">7<\/span> Choosing the Right Hosting Base for Brotli and Gzip<\/a><\/li><li><a href=\"#Putting_It_All_Together\"><span class=\"toc_number toc_depth_1\">8<\/span> Putting It All Together<\/a><\/li><\/ul><\/div>\n<h2><span id=\"How_Compression_Affects_Core_Web_Vitals\">How Compression Affects Core Web Vitals<\/span><\/h2>\n<p>Before touching configuration files, it helps to connect Brotli and Gzip to the metrics your SEO and marketing teams care about, especially <strong>Core Web Vitals<\/strong>. If you have not yet read it, our article <a href=\"https:\/\/www.dchost.com\/blog\/en\/core-web-vitals-ve-hosting-altyapisi-ttfb-lcp-ve-clsyi-sunucu-tarafinda-iyilestirme-rehberi\/\">Core Web Vitals and hosting: how server choices impact TTFB, LCP and CLS<\/a> is a good companion to this guide.<\/p>\n<p>The most important relationships:<\/p>\n<ul>\n<li><strong>LCP (Largest Contentful Paint)<\/strong>: Often depends on how quickly the HTML document and render-blocking CSS\/JS arrive. Compressing these assets directly shortens download time, especially on slower connections.<\/li>\n<li><strong>TTFB (Time To First Byte)<\/strong>: Compression itself does not reduce TTFB, but overly aggressive settings can <em>increase<\/em> TTFB if the server spends too long compressing each response. Good tuning is about balancing CPU cost and size savings.<\/li>\n<li><strong>INP\/FID (Interaction metrics)<\/strong>: Smaller JavaScript bundles load and execute sooner. Compression does not change CPU execution time, but it reduces the network component of the delay.<\/li>\n<li><strong>CLS<\/strong>: Compression does not directly affect layout stability, but faster CSS and fonts help the page stabilize quicker.<\/li>\n<\/ul>\n<p>In practice, we usually see 20\u201330% total transfer size reduction when Gzip is configured correctly, and often 10\u201320% extra savings when Brotli is enabled for modern browsers. On high-latency mobile connections, this can be the difference between a mediocre and a green LCP score.<\/p>\n<h2><span id=\"Brotli_vs_Gzip_What_You_Really_Need_to_Know\">Brotli vs Gzip: What You Really Need to Know<\/span><\/h2>\n<p>Both Brotli and Gzip compress HTTP responses and are negotiated via the <code>Accept-Encoding<\/code> and <code>Content-Encoding<\/code> headers. But there are important differences you should keep in mind when tuning your stack.<\/p>\n<h3><span id=\"Compression_efficiency_and_CPU_cost\">Compression efficiency and CPU cost<\/span><\/h3>\n<p>At similar CPU cost, Brotli usually produces smaller files than Gzip, especially for text-based content like HTML, CSS and JavaScript. But Brotli\u2019s higher levels can be very CPU intensive. For dynamic responses you generate on every request, you must be conservative.<\/p>\n<p>Useful mental model:<\/p>\n<ul>\n<li><strong>Gzip<\/strong> levels 1\u20139 (Nginx\/Apache): sweet spot for dynamic content is usually <strong>3\u20136<\/strong>.<\/li>\n<li><strong>Brotli<\/strong> levels 0\u201311 (Nginx\/Apache\/LiteSpeed): sweet spot for dynamic content is usually <strong>3\u20136<\/strong>; very high levels are better reserved for precompressed static assets.<\/li>\n<\/ul>\n<p>For static files (CSS\/JS built at deploy time), you can precompress with Brotli level 9\u201311 and store the resulting <code>.br<\/code> files on disk. The CPU cost is paid once during build, not on every request.<\/p>\n<h3><span id=\"Browser_support_and_HTTPS_requirement\">Browser support and HTTPS requirement<\/span><\/h3>\n<ul>\n<li>Gzip is universally supported (desktop and mobile, modern and legacy).<\/li>\n<li>Brotli (<code>br<\/code>) is supported by all major modern browsers, but typically only over HTTPS.<\/li>\n<\/ul>\n<p>That is why most production setups use this strategy:<\/p>\n<ul>\n<li>Enable <strong>Brotli<\/strong> first for modern HTTPS traffic.<\/li>\n<li>Keep <strong>Gzip<\/strong> as a fallback for older or non-Brotli clients.<\/li>\n<\/ul>\n<p>If you are still enabling HTTP\/2 and HTTP\/3 on your servers, have a look at <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\/\">our guide on how HTTP\/2 and HTTP\/3 affect SEO and Core Web Vitals<\/a>. Compression, modern HTTP protocols and TLS settings work best when tuned together.<\/p>\n<h3><span id=\"What_to_compress_and_what_not_to\">What to compress (and what not to)<\/span><\/h3>\n<p>Compression improves performance most when applied to <strong>text-based<\/strong> responses:<\/p>\n<ul>\n<li>HTML, JSON, XML<\/li>\n<li>CSS, JavaScript<\/li>\n<li>SVG, some font formats (WOFF\/WOFF2 \u2013 WOFF2 is already compressed but small extra gains are possible)<\/li>\n<\/ul>\n<p>It is usually <strong>not<\/strong> useful (or even harmful) to compress already-compressed binary formats:<\/p>\n<ul>\n<li>JPEG, PNG, WebP, AVIF images<\/li>\n<li>MP4, WebM videos<\/li>\n<li>ZIP, PDF and similar archives<\/li>\n<\/ul>\n<p>If you are still sending large unoptimized images, compression alone will not save you. Combine these settings with a proper image strategy like we described in <a href=\"https:\/\/www.dchost.com\/blog\/en\/gorsel-seo-ve-hosting-altyapisi-webp-avif-cdn-alt-alan-adlari-ve-gorsel-site-haritasi\/\">our WebP\/AVIF and image SEO guide<\/a>.<\/p>\n<h2><span id=\"Tuning_Brotli_and_Gzip_on_Nginx\">Tuning Brotli and Gzip on Nginx<\/span><\/h2>\n<p>Nginx is very flexible for compression, but configuration can become confusing across <code>http<\/code>, <code>server<\/code> and <code>location<\/code> blocks. Here is a clean approach we often use on VPS and dedicated servers at dchost.com.<\/p>\n<h3><span id=\"Step_1_Enable_modules\">Step 1: Enable modules<\/span><\/h3>\n<p>Most modern Nginx packages ship with Gzip support by default. Brotli may require:<\/p>\n<ul>\n<li>Installing an Nginx build with Brotli support, or<\/li>\n<li>Loading a Brotli dynamic module (e.g. <code>ngx_brotli<\/code>).<\/li>\n<\/ul>\n<p>Check with:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">nginx -V 2&gt;&amp;1 | grep -i brotli\n<\/code><\/pre>\n<p>If you see Brotli configured as a module, you can enable it; otherwise you must install a package or build including Brotli first. In another article we walked through this in detail: <a href=\"https:\/\/www.dchost.com\/blog\/en\/tls-1-3-ve-modern-sifrelerin-sicacik-mutfagi-nginx-apachede-ocsp-stapling-hsts-preload-ve-pfs-nasil-kurulur\/\">TLS 1.3, OCSP stapling and Brotli on Nginx<\/a>.<\/p>\n<h3><span id=\"Step_2_Baseline_Gzip_settings\">Step 2: Baseline Gzip settings<\/span><\/h3>\n<p>In your main Nginx config (often <code>\/etc\/nginx\/nginx.conf<\/code>), inside the <code>http {}<\/code> block:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">http {\n    gzip on;\n    gzip_comp_level 4;\n    gzip_min_length 1024;\n    gzip_proxied any;\n    gzip_vary on;\n\n    gzip_types\n        text\/plain\n        text\/css\n        text\/javascript\n        application\/javascript\n        application\/x-javascript\n        application\/json\n        application\/xml\n        application\/rss+xml\n        application\/atom+xml\n        application\/xhtml+xml\n        application\/xml+rss\n        image\/svg+xml\n        font\/ttf\n        font\/otf\n        font\/woff\n        font\/woff2;\n\n    # ... rest of your http config ...\n}\n<\/code><\/pre>\n<p>Notes:<\/p>\n<ul>\n<li><strong>gzip_comp_level 4<\/strong> is a good starting point. Increase to 5\u20136 if CPU usage is low and your pages are large.<\/li>\n<li><strong>gzip_min_length 1024<\/strong> avoids compressing tiny responses where overhead outweighs the benefit.<\/li>\n<li><strong>gzip_vary on<\/strong> adds <code>Vary: Accept-Encoding<\/code>, which is important for proxies and CDNs.<\/li>\n<\/ul>\n<h3><span id=\"Step_3_Brotli_settings_for_dynamic_responses\">Step 3: Brotli settings for dynamic responses<\/span><\/h3>\n<p>Once Brotli is available, add:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">http {\n    # Existing gzip settings ...\n\n    brotli on;\n    brotli_comp_level 4;\n    brotli_types\n        text\/plain\n        text\/css\n        text\/javascript\n        application\/javascript\n        application\/x-javascript\n        application\/json\n        application\/xml\n        application\/rss+xml\n        application\/atom+xml\n        application\/xhtml+xml\n        application\/xml+rss\n        image\/svg+xml\n        font\/ttf\n        font\/otf\n        font\/woff\n        font\/woff2;\n}\n<\/code><\/pre>\n<p>This configuration:<\/p>\n<ul>\n<li>Uses Brotli level 4 for a good balance between CPU and size.<\/li>\n<li>Leaves Gzip enabled as a fallback for clients that do not support <code>br<\/code>.<\/li>\n<\/ul>\n<p>For very busy dynamic sites, you can even start with <strong>brotli_comp_level 3<\/strong> and test CPU load.<\/p>\n<h3><span id=\"Step_4_Precompressed_static_assets\">Step 4: Precompressed static assets<\/span><\/h3>\n<p>For build pipelines (React\/Vue SPA, Laravel Mix, Webpack, Vite), generate <code>.br<\/code> and <code>.gz<\/code> files at deploy time. For example:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\"># Example with Brotli CLI\nfind dist -type f ( -name '*.js' -o -name '*.css' -o -name '*.html' ) \n  -exec brotli -f -q 10 {} ;\n\n# Example with gzip\nfind dist -type f ( -name '*.js' -o -name '*.css' -o -name '*.html' ) \n  -exec gzip -f -k -9 {} ;\n<\/code><\/pre>\n<p>Then in Nginx, enable serving the precompressed files:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">http {\n    gzip_static on;    # Use file.js.gz if it exists\n    brotli_static on;  # Use file.js.br if it exists\n}\n<\/code><\/pre>\n<p>With this pattern, the heaviest compression runs only during build or deploy, not on end-user requests, which is ideal for Core Web Vitals and server stability.<\/p>\n<h3><span id=\"Step_5_Testing_Nginx_compression\">Step 5: Testing Nginx compression<\/span><\/h3>\n<p>Use <code>curl<\/code> to verify which encoding you receive:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">curl -I -H 'Accept-Encoding: gzip' https:\/\/example.com\/\n\ncurl -I -H 'Accept-Encoding: br' https:\/\/example.com\/\n<\/code><\/pre>\n<p>In the response headers, confirm:<\/p>\n<ul>\n<li><code>Content-Encoding: gzip<\/code> or <code>Content-Encoding: br<\/code><\/li>\n<li><code>Vary: Accept-Encoding<\/code><\/li>\n<\/ul>\n<p>Then run a full-page test with tools such as PageSpeed Insights or WebPageTest. As a reference, see 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<\/a> so you interpret the results correctly.<\/p>\n<h2><span id=\"Tuning_Brotli_and_Gzip_on_Apache_mod_deflate_mod_brotli\">Tuning Brotli and Gzip on Apache (mod_deflate, mod_brotli)<\/span><\/h2>\n<p>On Apache, Gzip is handled by <code>mod_deflate<\/code> and Brotli by <code>mod_brotli<\/code>. Configuration can live in the main server config or in <code>.htaccess<\/code> (with some limitations).<\/p>\n<h3><span id=\"Step_1_Enable_the_modules\">Step 1: Enable the modules<\/span><\/h3>\n<p>In your Apache config (e.g. <code>httpd.conf<\/code> or <code>apache2.conf<\/code>):<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">LoadModule deflate_module modules\/mod_deflate.so\nLoadModule brotli_module  modules\/mod_brotli.so\n<\/code><\/pre>\n<p>Restart Apache after enabling:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">systemctl restart httpd   # or apache2\n<\/code><\/pre>\n<h3><span id=\"Step_2_Gzip_mod_deflate_configuration\">Step 2: Gzip (mod_deflate) configuration<\/span><\/h3>\n<p>In the global config or a virtual host:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">&lt;IfModule mod_deflate.c&gt;\n    AddOutputFilterByType DEFLATE \n        text\/plain \n        text\/html \n        text\/xml \n        text\/css \n        text\/javascript \n        application\/javascript \n        application\/x-javascript \n        application\/json \n        application\/xml \n        application\/xhtml+xml \n        application\/rss+xml \n        application\/atom+xml \n        image\/svg+xml \n        font\/ttf \n        font\/otf \n        font\/woff \n        font\/woff2\n\n    # Exclude already compressed formats\n    SetEnvIfNoCase Request_URI \n        .(?:gif|jpe?g|png|webp|avif|mp4|mp3|ogg|pdf|zip|gz|bz2|rar)$ \n        no-gzip dont-vary\n\n    # Compression level (1\u20139)\n    DeflateCompressionLevel 4\n\n    # Add proper Vary header\n    Header append Vary Accept-Encoding env=!dont-vary\n&lt;\/IfModule&gt;\n<\/code><\/pre>\n<p>This setup keeps compression at a moderate level and avoids re-compressing heavy binaries.<\/p>\n<h3><span id=\"Step_3_Brotli_mod_brotli_configuration\">Step 3: Brotli (mod_brotli) configuration<\/span><\/h3>\n<p>For Apache 2.4+ with <code>mod_brotli<\/code> available:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">&lt;IfModule mod_brotli.c&gt;\n    BrotliCompressionQuality 4        # 0\u201311\n    BrotliWindow 16                   # reasonable default\n\n    AddOutputFilterByType BROTLI_COMPRESS \n        text\/plain \n        text\/html \n        text\/xml \n        text\/css \n        text\/javascript \n        application\/javascript \n        application\/json \n        application\/xml \n        application\/xhtml+xml \n        application\/rss+xml \n        application\/atom+xml \n        image\/svg+xml \n        font\/ttf \n        font\/otf \n        font\/woff \n        font\/woff2\n\n    # Ensure Vary header\n    Header append Vary Accept-Encoding\n&lt;\/IfModule&gt;\n<\/code><\/pre>\n<p>Apache will negotiate between Brotli and Gzip based on the client\u2019s <code>Accept-Encoding<\/code> header. You can safely have both modules active.<\/p>\n<h3><span id=\"Step_4_htaccess_example\">Step 4: .htaccess example<\/span><\/h3>\n<p>If you are on shared hosting and only have <code>.htaccess<\/code> access, you can add a simplified version:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">&lt;IfModule mod_deflate.c&gt;\n    AddOutputFilterByType DEFLATE text\/html text\/plain text\/css \n        application\/javascript application\/json image\/svg+xml\n&lt;\/IfModule&gt;\n\n&lt;IfModule mod_brotli.c&gt;\n    AddOutputFilterByType BROTLI_COMPRESS text\/html text\/plain text\/css \n        application\/javascript application\/json image\/svg+xml\n&lt;\/IfModule&gt;\n<\/code><\/pre>\n<p>Keep in mind that some directives (like <code>DeflateCompressionLevel<\/code>) may require being set in the main config depending on your Apache configuration.<\/p>\n<h3><span id=\"Step_5_Testing_Apache_compression\">Step 5: Testing Apache compression<\/span><\/h3>\n<p>Again, use <code>curl<\/code> or browser DevTools:<\/p>\n<ul>\n<li>Look at the <strong>Network<\/strong> tab, check a CSS or JS file, and verify <code>Content-Encoding<\/code> is <code>gzip<\/code> or <code>br<\/code>.<\/li>\n<li>Confirm the <strong>Response Size<\/strong> in DevTools is significantly lower than the original.<\/li>\n<\/ul>\n<h2><span id=\"Brotli_and_Gzip_on_LiteSpeedOpenLiteSpeed\">Brotli and Gzip on LiteSpeed\/OpenLiteSpeed<\/span><\/h2>\n<p>LiteSpeed (and OpenLiteSpeed) integrate compression into the server core. If you are running WordPress with LiteSpeed Cache, some settings are also exposed through the plugin, but the server-level configuration determines the baseline behaviour.<\/p>\n<h3><span id=\"Server-level_compression_settings\">Server-level compression settings<\/span><\/h3>\n<p>In the LiteSpeed WebAdmin console (usually on port 7080), navigate to:<\/p>\n<ul>\n<li><strong>Configuration \u2192 Server \u2192 Tuning<\/strong> (or similar, depending on version).<\/li>\n<\/ul>\n<p>Key directives:<\/p>\n<ul>\n<li><strong>Enable Compression<\/strong>: set to <strong>Yes<\/strong>.<\/li>\n<li><strong>Compressible Types<\/strong>: list of MIME types (similar to Nginx\/Apache examples above).<\/li>\n<li><strong>Gzip Compression Level<\/strong>: 1\u20139; start at <strong>4<\/strong>.<\/li>\n<li><strong>Brotli Compression<\/strong>: enable if available; set quality around <strong>4<\/strong> for dynamic responses.<\/li>\n<\/ul>\n<p>LiteSpeed automatically handles negotiation between Brotli and Gzip for you. The main tuning is deciding which types to compress and at what levels.<\/p>\n<h3><span id=\"Virtual_host_and_context_overrides\">Virtual host and context overrides<\/span><\/h3>\n<p>You can override settings per virtual host or context. For example, in a virtual host configuration you might disable compression for a specific download directory:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">&lt;context \/downloads&gt;\n    compress      0\n&lt;\/context&gt;\n<\/code><\/pre>\n<p>This is useful if you serve large binary files that gain nothing from compression.<\/p>\n<h3><span id=\"LiteSpeed_Cache_plugin_WordPress\">LiteSpeed Cache plugin (WordPress)<\/span><\/h3>\n<p>If you run WordPress with LiteSpeed Cache, the plugin has a <strong>Browser<\/strong> or <strong>Optimization<\/strong> section that can toggle Gzip\/Brotli. However:<\/p>\n<ul>\n<li>We recommend controlling compression primarily at the <strong>server level<\/strong> and using the plugin features for page cache and asset optimization.<\/li>\n<li>Ensure you do not have conflicting settings (for example, the plugin trying to disable server-level compression).<\/li>\n<\/ul>\n<p>For a broader performance strategy on LiteSpeed-based hosting, see our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/litespeed-cache-eklentisi-ile-wordpress-hizlandirma-paylasimli-hosting-icin-detayli-ayar-rehberi\/\">speeding up WordPress with LiteSpeed Cache on shared hosting<\/a>.<\/p>\n<h2><span id=\"Practical_Tuning_Strategy_Across_All_Web_Servers\">Practical Tuning Strategy Across All Web Servers<\/span><\/h2>\n<p>Regardless of whether you use Nginx, Apache or LiteSpeed, the high-level strategy is very similar. Here is how we approach Brotli and Gzip tuning on real projects at dchost.com.<\/p>\n<h3><span id=\"1_Prioritize_the_right_content_types\">1. Prioritize the right content types<\/span><\/h3>\n<p>Focus on compressing:<\/p>\n<ul>\n<li><strong>HTML and JSON<\/strong>: these control the start of rendering and data APIs.<\/li>\n<li><strong>Critical CSS and JavaScript<\/strong>: anything that blocks the first render.<\/li>\n<li><strong>SVG icons and fonts<\/strong>: helpful but secondary.<\/li>\n<\/ul>\n<p>Skip or explicitly exclude:<\/p>\n<ul>\n<li>Images (JPEG\/PNG\/WebP\/AVIF)<\/li>\n<li>Videos<\/li>\n<li>Archives (ZIP, GZ, RAR, etc.)<\/li>\n<\/ul>\n<h3><span id=\"2_Choose_safe_compression_levels\">2. Choose safe compression levels<\/span><\/h3>\n<p>Our default starting values when we provision new VPS or dedicated servers:<\/p>\n<ul>\n<li><strong>Gzip<\/strong>: level 4 for dynamic content; 6\u20139 for precompressed static files generated at build time.<\/li>\n<li><strong>Brotli<\/strong>: level 4 for dynamic; 9\u201311 for precompressed static assets.<\/li>\n<\/ul>\n<p>Then we monitor:<\/p>\n<ul>\n<li>CPU usage under peak traffic.<\/li>\n<li>Average TTFB from monitoring tools.<\/li>\n<li>Error rates (e.g. timeouts if compression is too heavy for the hardware).<\/li>\n<\/ul>\n<p>If CPU is underutilized, you can gently raise levels. If CPU saturates during spikes, reduce them.<\/p>\n<h3><span id=\"3_Align_compression_with_caching_and_CDN_strategy\">3. Align compression with caching and CDN strategy<\/span><\/h3>\n<p>Compression is much more powerful when combined with correct caching headers and a CDN. For detailed header rules, see <a href=\"https:\/\/www.dchost.com\/blog\/en\/tarayici-ve-cdn-onbellekleme-neden-bu-kadar-kritik\/\">our guide to HTTP Cache-Control, ETag and CDN rules<\/a>, and for the CDN concept itself, the article <a href=\"https:\/\/www.dchost.com\/blog\/en\/cdn-nedir-ne-zaman-gerekir-trafik-ve-lokasyona-gore-karar-rehberi\/\">What is a CDN and when do you really need one<\/a>.<\/p>\n<p>Key alignment points:<\/p>\n<ul>\n<li><strong>Cache at the edge<\/strong>: When responses are both compressed and cached by the CDN, your origin server does almost no compression work for cache hits.<\/li>\n<li><strong>Vary header<\/strong>: Ensure <code>Vary: Accept-Encoding<\/code> is present so the CDN can store separate variants for Brotli and Gzip when needed.<\/li>\n<li><strong>Warm cache intelligently<\/strong>: For very large catalogs or SPAs, consider warm-up scripts that hit key pages to populate compressed and cached versions before big campaigns.<\/li>\n<\/ul>\n<h3><span id=\"4_Sync_with_TLS_and_HTTP_protocol_tuning\">4. Sync with TLS and HTTP protocol tuning<\/span><\/h3>\n<p>Brotli is most beneficial over HTTPS (where browsers enable it). If you are still on older TLS settings or only HTTP\/1.1, you are leaving performance on the table. A modern setup typically includes:<\/p>\n<ul>\n<li>TLS 1.2 and <strong>TLS 1.3<\/strong> with strong cipher suites.<\/li>\n<li>HTTP\/2 enabled at minimum; consider HTTP\/3 for mobile performance.<\/li>\n<li>OCSP stapling and session resumption.<\/li>\n<\/ul>\n<p>We covered these in depth in our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/tls-1-3-ve-modern-sifrelerin-sicacik-mutfagi-nginx-apachede-ocsp-stapling-hsts-preload-ve-pfs-nasil-kurulur\/\">TLS 1.3, OCSP stapling and modern HTTPS on Nginx and Apache<\/a>. Compression, TLS and modern protocols together create a visible improvement in Core Web Vitals.<\/p>\n<h3><span id=\"5_Measure_impact_on_Core_Web_Vitals_not_just_transfer_size\">5. Measure impact on Core Web Vitals, not just transfer size<\/span><\/h3>\n<p>After enabling or tuning compression, measure:<\/p>\n<ul>\n<li><strong>LCP<\/strong>: particularly on mobile connections and from key geographies where your users are.<\/li>\n<li><strong>TTFB<\/strong>: ensure it does not regress due to CPU overhead.<\/li>\n<li><strong>Total bytes transferred<\/strong> for HTML\/CSS\/JS.<\/li>\n<\/ul>\n<p>Tools like PageSpeed Insights, Search Console Core Web Vitals reports, and RUM (real user monitoring) scripts give you a complete picture. A 20\u201330% reduction in transfer size that yields a clear drop in LCP is a success; a small size gain that increases CPU and TTFB is not.<\/p>\n<h2><span id=\"Choosing_the_Right_Hosting_Base_for_Brotli_and_Gzip\">Choosing the Right Hosting Base for Brotli and Gzip<\/span><\/h2>\n<p>Compression is mostly a configuration issue, but hardware and hosting architecture still matter. On very weak or oversold servers, high compression levels can push CPU to 100% during traffic spikes and actually harm performance.<\/p>\n<p>On our side at dchost.com, when we design hosting plans for dynamic sites (WordPress, WooCommerce, Laravel, Node.js), we consider:<\/p>\n<ul>\n<li><strong>vCPU capacity<\/strong>: enough headroom for PHP\/Node plus Brotli\/Gzip work.<\/li>\n<li><strong>Fast NVMe storage<\/strong>: to serve precompressed static assets quickly from disk.<\/li>\n<li><strong>Network throughput<\/strong>: so you can benefit fully from reduced payloads.<\/li>\n<\/ul>\n<p>If your site is growing, it may be time to move from basic shared hosting to a VPS or even a dedicated server, where you have full control over Nginx\/Apache\/LiteSpeed and can implement all of the settings in this article. For a deeper dive into planning resources for modern PHP apps, see our guides on <a href=\"https:\/\/www.dchost.com\/blog\/en\/wordpress-icin-sunucu-tarafi-optimizasyon-php-fpm-opcache-redis-ve-mysql-ile-neyi-ne-zaman-nasil-ayarlamalisin\/\">server-side optimization for WordPress<\/a> and on <a href=\"https:\/\/www.dchost.com\/blog\/en\/nvme-vps-hosting-rehberi-hizin-nereden-geldigini-nasil-olculdugunu-ve-gercek-sonuclari-beraber-gorelim\/\">NVMe VPS hosting and where the speed really comes from<\/a>.<\/p>\n<h2><span id=\"Putting_It_All_Together\">Putting It All Together<\/span><\/h2>\n<p>Well-tuned Brotli and Gzip compression settings are one of the simplest server-side optimizations you can make for better Core Web Vitals. The key is to avoid extremes: do not leave compression disabled, but also do not push levels so high that your CPU becomes the new bottleneck.<\/p>\n<p>On Nginx, Apache and LiteSpeed alike, the winning pattern looks like this:<\/p>\n<ul>\n<li>Enable both <strong>Brotli and Gzip<\/strong>, with Brotli prioritized for modern browsers and Gzip as a fallback.<\/li>\n<li>Compress <strong>HTML, CSS, JS and JSON<\/strong>, skip already compressed binaries.<\/li>\n<li>Use <strong>moderate compression levels<\/strong> (3\u20136) for dynamic responses and heavy levels for precompressed build-time assets.<\/li>\n<li>Combine compression with <strong>proper caching headers, a CDN and modern TLS\/HTTP<\/strong> to unlock the full benefit.<\/li>\n<li>Measure impact on <strong>LCP and TTFB<\/strong>, not just on transfer size numbers.<\/li>\n<\/ul>\n<p>At dchost.com we apply these principles when we prepare new servers, migrate busy sites or audit Core Web Vitals for customers. If you are planning a move to a VPS, dedicated server or colocation and want an environment where Brotli, HTTP\/3, TLS 1.3 and modern caching strategies are first-class citizens, building that stack on a solid hosting base matters as much as the config snippets themselves.<\/p>\n<p>Take this article as a checklist: start by enabling safe compression, then iterate on levels, caching and CDN. Combined with the other tuning guides we have shared, you can bring your site into the green zone for Core Web Vitals with changes that are fully under your control on the server side.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>When we review slow sites on our infrastructure at dchost.com, one pattern appears again and again: HTML, CSS and JavaScript are being sent completely uncompressed or with poorly tuned settings. Core Web Vitals like LCP and TTFB suffer, even though the server itself is not overloaded. The quickest win in many of these audits is [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":3620,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-3619","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\/3619","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=3619"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/3619\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/3620"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=3619"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=3619"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=3619"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}