Maximum speed: how to squeeze the maximum out of your web server
When scaling web projects, developers often run into limitations of traditional server stacks, such as Nginx + PHP-FPM or Apache. As traffic grows, the server starts consuming an excessive amount of RAM and CPU resources, increasing server response time (TTFB) and slowing down the website.
This problem is solved by OpenLiteSpeed (OLS) — a free, high-performance open-source web server. It is designed to handle tens of thousands of concurrent connections with minimal resource consumption, using an event-driven architecture. In this article, we will provide step-by-step instructions for fine-tuning OpenLiteSpeed to maximize your website speed.
Why OpenLiteSpeed surpasses Nginx and Apache
Unlike Apache, which creates a separate process for each connection, and Nginx, which requires third-party modules for complex caching logic, OpenLiteSpeed has several built-in killer features:
- Built-in LSCache module. Allows caching dynamic pages directly in the web server RAM, bypassing PHP and MySQL calls. In terms of efficiency, LSCache surpasses external solutions like Varnish.
- Built-in HTTP/3 (QUIC) support. Works right out of the box without the need for manual web server compilation from source with experimental patches.
- Full compatibility with .htaccess files. Allows easily migrating projects from Apache without rewriting redirect rules (rewrite rules), which is critical for CMS like WordPress, OpenCart, and Drupal.
“Switching to the OpenLiteSpeed + LiteSpeed Cache combo allows reducing the server response time (TTFB) of dynamic CMS pages from the typical 500-800 ms to a stable 20-50 ms, effectively turning a dynamic website into a static one for most users.”
Step 1. Fine-tuning LSCache caching
The LSCache module is the main weapon of OpenLiteSpeed. For it to work effectively, it needs to be activated in the OLS control console (WebAdmin Console) on the tab Server Configuration -> Modules, adding the module cache with the following parameters:
enableCache 1— enables server-side caching globally.qsCache 1— allows caching of pages with query parameters (GET requests).reqCookieCache 1— allows caching for unique cookies.ignoreReqCacheCtrl 1— forces the server to ignore browser headers requesting a forced page refresh (for example, when pressing Ctrl+F5), protecting the backend from DDoS load.
Step 2. Brotli and Gzip compression setup
Compressing transmitted files reduces traffic volume by 50-80%, which is critical for users with slow mobile internet.
Brotli is a more modern and efficient compression algorithm from Google, outperforming traditional Gzip by 15-25%. In OpenLiteSpeed, configure compression in section Server Configuration -> Tuning -> Gzip/Brotli Compression:
- Enable Compression:
Yes. - Enable Brotli:
Yes. - Compression Level (Gzip):
6(optimal balance between compression and CPU load). - Brotli Compression Level:
4(for real-time dynamic content) and6(for static content).
Step 3. HTTP/3 QUIC protocol activation
The HTTP/3 protocol operates over the UDP transport protocol (instead of TCP). It resolves the head-of-line blocking issue, accelerating page load speeds on mobile networks when switching between cell towers or Wi-Fi.
To set up HTTP/3 on OpenLiteSpeed:
- Go to Listeners and make sure you have an SSL listener configured on port 443.
- In the listener settings, specify Enable HTTP/3:
Yes. - Configure firewall rules on the server: open incoming port
443 UDP(command for CentOS/RHEL:firewall-cmd --add-port=443/udp --permanent). - Make sure the web server sends the header
Alt-Svc: h3=":443"; ma=2592000, which informs client browsers about HTTP/3 protocol support.
Conclusion
Using OpenLiteSpeed is one of the simplest and most cost-effective ways to speed up a project without buying expensive server capacity. Finely tuned LSCache cache, modern Brotli compression, and the HTTP/3 protocol will provide your website with instant response, stability during peak loads, and loyalty from Google and Yandex search engines.