24 August 2025

NGINX VS Litespeed, a weighted comparison in 2025.

Litespeed's shortcomings compared to NGINX, from the lack of ZSTD compression, to the lack of support for Early Hints.

NGINX VS LiteSpeed ​​2025

Introduction

In the modern web server landscape, NGINX and LiteSpeed ​​are often compared as alternatives to Apache for achieving high performance without compromise. In recent years, LiteSpeed ​​has become very popular in the hosting market, especially shared, because it allows you to "raise the performance bar" compared to classic Apache-based LAMP solutions with relatively low operational effort . It is a "turnkey" product that integrates application caches and a good set of defaults, so many companies – often made up of junior figures or in any case with limited system skills – are able to provide services perceived as "fast" without having to master the fine-tuning of NGINX , reverse proxy , FastCGI cache or full-page cache (e.g. Varnish ).

This does not change the fact that, despite the hype and aggressive marketing, the technical facts matter . And on two strategic fronts for real-world performance in 2025, LiteSpeed ​​has shortcomings compared to NGINX: Zstandard (ZSTD) compression and HTTP 103 Early Hints.

Below we analyze why these two points matter (a lot), what NGINX offers today , what is missing in LiteSpeed, and what concrete impacts you can expect in terms of TTFB , content delivery , and Core Web Vitals.

Zstandard (ZSTD): Why It's the "Right" Compression in 2025

Zstandard (ZSTD) is a modern compression algorithm, designed for be quick to compress and even quicker to decompress, with competitive compression ratios. Since 2024, it has become truly viable on the web because browsers main ones support it natively as Content-Encoding:

What NGINX offers today on ZSTD

NGINX, due to its modular nature, can enable ZSTD via a widely used dynamic module (ngx_http_zstd_filter/static) and packaged by multiple distributions:

In other words: on NGINX ZSTD is actually deployable in production today, without exotic patches, using third-party modules well maintained and available in the repos of the most common distros. This allows you to to serve Content-Encoding: zstd when the client negotiates it, reducing CPU load, lowering the compression times and improving TTFB of dynamic responses compared to Brotli, with the same perceived quality.

Brotli VS Zstandard Benchmark

To confirm the practical benefits, Cloudflare – which uses NGINX as the basis of its pipeline – has introduced ZSTD at the edge: in internal tests, ZSTD compresses up to 42% faster than Brotli while maintaining close ratios, and beats GZIP by ~ 11,3% in average efficiency. The Cloudflare Blog

ZSTD NGINX BROTLI Hosting Banner

Where LiteSpeed ​​falls behind on ZSTD

LiteSpeed (including OpenLiteSpeed) documents support for Gzip e Brotli, but not at Zstandard including Content-Encoding for web traffic to the browser. Their official compression documentation doesn't mention ZSTD. LiteSpeed ​​Documentation

To “add” ZSTD to LiteSpeed the only practical workaround is place a reverse proxy upstream (typically a CDN including Cloudflare) That recompress to ZSTD towards compatible browsers. Cloudflare, in fact, offers ZSTD at the edge and allows you to trade it based on theAccept-Encoding of the client. Cloudflare Docs

This solution, however, introduces a significant trade-off: in the event of a cache miss, the CDN adds at least one hop and an extra fetch step from the origin, which can worsen TTFB compared to direct delivery (especially for non-cacheable dynamic HTML) – this is why many CDN articles and guides insist on improving cache hits and carefully managing Tiered Cache topologies to reduce latency.

Conclusion of the point: a infrastructure parity, with NGINX today is easier bring ZSTD directly on board (server-side) without forcing a CDN switch, while with LiteSpeed ​​you are forced to interpose an external reverse proxy to obtain the same Content-Encoding. This limit the optimization of TTFB extension and introduces addictions e complexity not always desired.

103 Early Hints: NGINX's Advantage in 2025

Early Hints Diagram

- Early Hints (HTTP 103) they are answers informative send before of the final response, which allow the browser to start right away to pre-connect or preload critical resources (<link rel="preload">/preconnect) while the application is still generating the page. The result is a shortening the critical path of rendering and tangible improvements on FCP/LCPGoogle/Chrome documentation clearly describes the mechanism and benefits. Chrome for Developers

What NGINX offers today on Early Hints

On June 24, 2025, NGINX officially announced support for 103 Early Hints in the 1.29.0 mainline . This is a native feature designed to prepare the browser for initial loading and speed up the initial loading phase. For those using NGINX today (August 24, 2025), this is a real possibility to exploit to squeeze precious milliseconds out of server think-time . blog.nginx.org

Where LiteSpeed ​​Falls Behind on Early Hints

To date, LiteSpeed ​​does not document native support for 103 Early Hints . On the official forum, the topic has been the subject of feature requests since 2022 and subsequent discussions, without a server-side availability announcement comparable to that of NGINX. litespeedtech.com

One might argue that "a CDN can send 103s instead of the server." This is true in some cases, but it 's no substitute for end-to-end support on the origin side: the best Early Hints are those coordinated with the application logic (template, dependency graph of critical resources) and with minimal delays between the issuance of the 103s and the final response. Sending everything to the CDN edge—in addition to the aforementioned limits on cache missesreduces the control and granularity with which the critical path is optimized . (For general context on Early Hints and browser-side benefits, see also MDN.) MDN Web Docs

Bottom line: NGINX has Early Hints today ; LiteSpeed ​​does not. If perceived speed (LCP) is a priority, this is a real advantage that adds to the ability to use ZSTD directly on the origin.

Practical impacts on TTFB, LCP, and CPU costs

Both ZSTD and Early Hints touch on different stages of the supply chain:

  • ZSTD reduces server-side compression times and often bytes transferred (compared to GZIP), with extremely fast client-side decompression ; it's particularly effective on dynamic HTML and non-cacheable responses, where compressing faster directly improves hot TTFB . (Cloudflare measured average compression times 42% faster than Brotli at a very close ratio.) The Cloudflare Blog

  • Early Hints anticipate connections and preload critical resources, overlapping network latency with the final response generation time . The gain is observed in FCP/LCP and perceived rendering time . (Guidelines and measurements are detailed in Google's developer articles.) Chrome for Developers

By adding the two effects, NGINX in 2025 enables “supply chain” optimizations that are difficult to replicate with LiteSpeed ​​without external “prostheses” (CDN) and with more architectural constraints.

Common Objections (and Responses)

“But LiteSpeed ​​is simpler and includes native caching (LSCache)”
Real: LSCache è comfortable and it helps a lot in shared hosting contexts. However, the simplicity does not replace missing features. If the goal is to bring ZSTD e Early Hints today on the origin, Nginx it's the fastest way and technically complete.

“CDN does ZSTD anyway”
Yup, se wish to bind you to the CDN and to accept and cache miss let's introduce a extra latency. For dynamic HTML or custom content, enable ZSTD directly on the server is often the best choice. (On the role of cache miss in inflating the TTFB see technical analysis and best practices). Amazon Web Services Inc.The Cloudflare Blog

“Early Hints can be emulated with preconnect or HTTP/2 Push”
Server Push was deprecated/abandoned by major browsers; Early Hints I am the modern substitute and standard to orchestrate preload/preconnect before of the definitive answer. Nginx supports them natively from June 2025, Litespeed will not.

Adoption Data: Where High-Traffic Sites Are Going

Public technology databases ( SimilarTech has now merged into Similarweb ) confirm a consistent picture: NGINX continues to be widely adopted among the highest-traffic sites, while LiteSpeed ​​is growing but lagging in the top rankings.

NGINX VS LITESPEED

Similarweb's technology pages provide usage overviews for NGINX and LiteSpeed ; in parallel, W3Techs reports an NGINX share of ~33–34% and LiteSpeed ​​~14–15% of total ranked sites (updated August 2025). Similarweb w3techs.com

Note: Exact numbers vary by methodology (estimation vs. survey, sample vs. top N, etc.), but the trend across sources is consistent : NGINX dominates the top tiers and enterprise-grade ecosystem, while LiteSpeed ​​is strong in shared/bulk hosting and specific segments.

A word about the hype and the expertise of the insiders

It's worth reiterating frankly: LiteSpeed ​​has made life easier for many hosting companies, especially those lacking robust expertise in NGINX , proxy caching, FastCGI caching , or Varnish . This doesn't make it a bad product; in fact, as a starting point, it played (and still plays) a role.

The technical point, however, is another: with NGINX – already in the Open Source version (not only in the commercial edition NGINX Plus ) it is possible to bring both the 103 Early Hints and the Zstandard (ZSTD) compression into production , while with LiteSpeed ​​these features are not available even in the commercial version , which is also paid , which inevitably passes the costs on to the buyer and the end customer.

Furthermore, “real” research and development – the one that requires compile from source, integrate forms not pre-installed, manage advanced configurations, ask repeatable tests and measurements before of the go-live – it's not within reach of those who have as their only goal sell pre-packaged packagesBringing a “perfect” service into production means knowing how to: choose toolchain e compilation flag adequate, orchestrate staging environments e canary release, to collect telemetry (RUM and synthetic), profile by collecting Tracks e flamegraph, iterate on benchmarking e A / B test, and only then fix e default solid. This craftsmanship – often necessary to enable and optimize features such as ZSTD ed Early Hints on NGINX Open Source – you don't buy it "off the shelf" and requires skills that go beyond the assembly of a turnkey solution.

In 2025, once again presenting LiteSpeed ​​as “the best performing solution” without mentioning the lack of ZSTD and the absence of Early Hints is unfair to customers. These are two technical pieces that, together, make a measurable difference in delivery times ( TTFB ), perceived speed ( LCP ), and, in general, the user experience.

Plesk or cPanel Quote Banner

Operational recommendations

With a pragmatic look , here's how we can move forward in 2025:

If you stay on LiteSpeed

  • Currency severely the use of a CDN that offers ZSTD client-side (e.g. Cloudflare) to get you closer to the benefits of Content-Encoding: zstd. Manage the strategy of cache warming and Tiered Cache for limit the impact of the cache miss on TTFB extension. The Cloudflare Blog
  • For the Early Hints, there is no origin support at the moment: the only way is delegate to the CDN where possible, knowing that it is not equivalent to management app-aware server-side. Chrome for Developers

If you can choose NGINX

  • Nginx you consent today to activate ZSTD via form (ngx_http_zstd_filter/static) with ready packages on multiple distros; plan A/B tests on Dynamic HTML and static resources to calibrate the compression levels.
  • Enable 103 Early Hints (NGINX 1.29.0+), precisely defining which assets include in Link: rel=preload initials and when send them, to maximize the effect on FCP/LCP. blog.nginx.org Chrome for Developers

Measure, always

  • Instrumenta Server Timing, compare TTFB extension in cache HIT vs MISS and observe the field data (CrUX) – especially on pages non-cacheableGoogle/AWS technical articles show how to properly decompose end-to-end latency. web.dev

Conclusions

Let's summarize the technical facts updated to August 24, 2025 :

  • Zstandard (ZSTD) is supported by major browsers and deployable on NGINX via popular/packaged modules. LiteSpeed ​​does not natively support client-side ZSTD: to get it, you need an upstream CDN (e.g., Cloudflare), with the associated trade-offs on TTFB for cache misses.

  • Early Hints (HTTP 103) are available in NGINX (as of June 24, 2025 , v. 1.29.0 mainline ) and are not documented in LiteSpeed; the theme is only present as a feature request in the LiteSpeed ​​communities.

  • The practical impacts are clear: ZSTD improves CPU/TTFB , especially for dynamic responses; Early Hints anticipates preconnect/preload and improves FCP/LCP . Together, they give NGINX a real advantage in 2025.

  • Market Adoption : Independent observers show NGINX significantly more widespread overall and at the “high” end of traffic, with LiteSpeed ​​growing but stronger in mass-market hosting. (SimilarTech/Similarweb for technology overviews; W3Techs for updated percentages).

Once again, therefore, it's important to reiterate with technical honesty what LiteSpeed ​​enthusiasts often fail to tell end customers: LiteSpeed ​​currently lacks two key features for modern optimization of delivery and speed perception . Presenting it as the "best all-around" choice hides substantial differences and pushes decisions driven by marketing rather than engineering.

Banner Quote Fast Hosting Said

For those aiming for top-level performance – especially on dynamic projects , with real traffic and stringent Core Web VitalsNGINX in 2025 offers concrete and immediately usable tools (ZSTD + Early Hints) that LiteSpeed ​​does not yet offer on-origin . The market direction, demonstrated by adoption statistics and the attention of the main players (browsers, CDNs, vendors), is all going towards this: open standards, modular components, cutting-edge features integrated at the server level . And in this field, NGINX remains the reference.

At Managed Server Srl, we have always stood out for our tailored, technical approach to managing and solving Web Performance issues . We will continue to invest time in research and development to bring a server-side stack into production that surpasses what a commercial, general-purpose product like LiteSpeed ​​can offer: this will ensure and protect our customers and their businesses . This choice also means sacrificing numbers and sales and giving up easier revenue that we could achieve by conforming to the mindset and modus operandi of certain "colleagues." We prefer not to become "one of many ," but to continue to do true, measurable, and results-oriented engineering , rather than relying on prepackaged solutions driven solely by marketing.

Do you have doubts? Don't know where to start? Contact us!

We have all the answers to your questions to help you make the right choice.

Chat with us

Chat directly with our presales support.

0256569681

Contact us by phone during office hours 9:30 - 19:30

Contact us online

Open a request directly in the contact area.

DISCLAIMER, Legal Notes and Copyright. RedHat, Inc. holds the rights to Red Hat®, RHEL®, RedHat Linux®, and CentOS®; AlmaLinux™ is a trademark of the AlmaLinux OS Foundation; Rocky Linux® is a registered trademark of the Rocky Linux Foundation; SUSE® is a registered trademark of SUSE LLC; Canonical Ltd. holds the rights to Ubuntu®; Software in the Public Interest, Inc. holds the rights to Debian®; Linus Torvalds holds the rights to Linux®; FreeBSD® is a registered trademark of The FreeBSD Foundation; NetBSD® is a registered trademark of The NetBSD Foundation; OpenBSD® is a registered trademark of Theo de Raadt; Oracle Corporation holds the rights to Oracle®, MySQL®, MyRocks®, VirtualBox®, and ZFS®; Percona® is a registered trademark of Percona LLC; MariaDB® is a registered trademark of MariaDB Corporation Ab; PostgreSQL® is a registered trademark of PostgreSQL Global Development Group; SQLite® is a registered trademark of Hipp, Wyrick & Company, Inc.; KeyDB® is a registered trademark of EQ Alpha Technology Ltd.; Typesense® is a registered trademark of Typesense Inc.; REDIS® is a registered trademark of Redis Labs Ltd; F5 Networks, Inc. owns the rights to NGINX® and NGINX Plus®; Varnish® is a registered trademark of Varnish Software AB; HAProxy® is a registered trademark of HAProxy Technologies LLC; Traefik® is a registered trademark of Traefik Labs; Envoy® is a registered trademark of CNCF; Adobe Inc. owns the rights to Magento®; PrestaShop® is a registered trademark of PrestaShop SA; OpenCart® is a registered trademark of OpenCart Limited; Automattic Inc. holds the rights to WordPress®, WooCommerce®, and JetPack®; Open Source Matters, Inc. owns the rights to Joomla®; Dries Buytaert owns the rights to Drupal®; Shopify® is a registered trademark of Shopify Inc.; BigCommerce® is a registered trademark of BigCommerce Pty. Ltd.; TYPO3® is a registered trademark of the TYPO3 Association; Ghost® is a registered trademark of the Ghost Foundation; Amazon Web Services, Inc. owns the rights to AWS® and Amazon SES®; Google LLC owns the rights to Google Cloud™, Chrome™, and Google Kubernetes Engine™; Alibaba Cloud® is a registered trademark of Alibaba Group Holding Limited; DigitalOcean® is a registered trademark of DigitalOcean, LLC; Linode® is a registered trademark of Linode, LLC; Vultr® is a registered trademark of The Constant Company, LLC; Akamai® is a registered trademark of Akamai Technologies, Inc.; Fastly® is a registered trademark of Fastly, Inc.; Let's Encrypt® is a registered trademark of the Internet Security Research Group; Microsoft Corporation owns the rights to Microsoft®, Azure®, Windows®, Office®, and Internet Explorer®; Mozilla Foundation owns the rights to Firefox®; Apache® is a registered trademark of The Apache Software Foundation; Apache Tomcat® is a registered trademark of The Apache Software Foundation; PHP® is a registered trademark of the PHP Group; Docker® is a registered trademark of Docker, Inc.; Kubernetes® is a registered trademark of The Linux Foundation; OpenShift® is a registered trademark of Red Hat, Inc.; Podman® is a registered trademark of Red Hat, Inc.; Proxmox® is a registered trademark of Proxmox Server Solutions GmbH; VMware® is a registered trademark of Broadcom Inc.; CloudFlare® is a registered trademark of Cloudflare, Inc.; NETSCOUT® is a registered trademark of NETSCOUT Systems Inc.; ElasticSearch®, LogStash®, and Kibana® are registered trademarks of Elastic NV; Grafana® is a registered trademark of Grafana Labs; Prometheus® is a registered trademark of The Linux Foundation; Zabbix® is a registered trademark of Zabbix LLC; Datadog® is a registered trademark of Datadog, Inc.; Ceph® is a registered trademark of Red Hat, Inc.; MinIO® is a registered trademark of MinIO, Inc.; Mailgun® is a registered trademark of Mailgun Technologies, Inc.; SendGrid® is a registered trademark of Twilio Inc.; Postmark® is a registered trademark of ActiveCampaign, LLC; cPanel®, LLC owns the rights to cPanel®; Plesk® is a registered trademark of Plesk International GmbH; Hetzner® is a registered trademark of Hetzner Online GmbH; OVHcloud® is a registered trademark of OVH Groupe SAS; Terraform® is a registered trademark of HashiCorp, Inc.; Ansible® is a registered trademark of Red Hat, Inc.; cURL® is a registered trademark of Daniel Stenberg; Facebook®, Inc. owns the rights to Facebook®, Messenger® and Instagram®. This site is not affiliated with, sponsored by, or otherwise associated with any of the above-mentioned entities and does not represent any of these entities in any way. All rights to the brands and product names mentioned are the property of their respective copyright holders. All other trademarks mentioned are the property of their respective registrants. MANAGED SERVER® is a European registered trademark of MANAGED SERVER SRL, with registered office in Via Flavio Gioia, 6, 62012 Civitanova Marche (MC), Italy and operational headquarters in Via Enzo Ferrari, 9, 62012 Civitanova Marche (MC), Italy.

JUST A MOMENT !

Have you ever wondered if your hosting sucks?

Find out now if your hosting provider is hurting you with a slow website worthy of 1990! Instant results.

Close the CTA
Back to top