Table of contents of the article:
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:
-
Chrome 123 (March 2024) introduced support for
zstd. Chrome for Developers -
Firefox 126 (May 2024) added support for
zstd. FirefoxMDN WebDocs -
The standard for HTTP usage is formalized in RFC 8878 (with updates in 2024 on “window sizing” in RFC 9659 ). datatracker.ietf.org rfc-editor.org
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:
-
Open source module: zstd-nginx-module (precompressed file compressor/service
.zst). GitHub -
Official distro packages (Eg. Alpine Linux:
nginx-mod-http-zstd, forms.sofilter + static). pkgs.alpinelinux.org+2pkgs.alpinelinux.org+2
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.
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
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 (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 misses — reduces 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.
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.
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=preloadinitials 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.
For those aiming for top-level performance – especially on dynamic projects , with real traffic and stringent Core Web Vitals – NGINX 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.