[CASE STUDY] 100/97 Lighthouse on High‑Traffic News Portal WITHOUT CDN — Pure LSCache + LSWS Optimization

WebPrestige

WebPrestige

New Member
#1
#1
Hello everyone,
I would like to share some performance results from a WordPress news site (protinews.com.gr) running on LiteSpeed Web Server with LSCache. The site uses the Newspaper theme and receives heavy daily traffic with constant updates. No CDN is used at the moment.
I am posting this mainly to discuss the LSCache configuration and server tuning that helped us reach very good Lighthouse scores on both desktop and mobile.
Desktop results (March 2026): LCP 1.9s, INP 16ms, TBT 20ms, CLS 0.05, Speed Index 0.7s, Performance score 100.
Mobile results: LCP 2.4s, INP 87ms, TBT 0ms, CLS 0.00, Speed Index 1.8s, Performance score 97.
These numbers were achieved without Cloudflare or any external CDN. Only LSCache and server‑level optimization were used.
Some of the techniques applied:
  • public cache for all visitors
  • private cache for logged‑in users
  • ESI for dynamic blocks
  • guest mode enabled
  • selective JS defer
  • HTML/CSS/JS optimization
  • Brotli compression
  • HTTP/3 enabled
  • PHP LSAPI tuning
  • reduced DOM size
  • removed heavy theme modules
The goal was to see how far LSCache can go on its own before adding QUIC.cloud. . The next step will be enabling QUIC.cloud CDN to improve TTFB and global delivery.
I am sharing this to exchange ideas with the community. If anyone has suggestions for further improvements or wants more details about the configuration, I would be happy to discuss.


Happy to answer questions or share more configuration details if needed.
 

Attachments

serpent_driver

serpent_driver

Well-Known Member
#2
#2
A PageSpeed score has nothing to with "Speed of Page" or performance or good or bad the LSWS configuration is. PageSpeed measures how fast the content is displayed AFTER the loading assets are displayed in browser window or in other words, PageSpeed measures how fast a page "feels". PageSpeed (and page optimization) is just browser cosmetic. Learn more about this narrative: https://www.cachecrawler.com/Blog/W...nce-Doesnt-Start-With-Optimization::6601.html

Or more uncomfortable truths about PageSpeed and optimization. https://www.cachecrawler.com/Blog:::42.html

LiteCache Rush - WordPress Performance starts with Prevention, not with optimization. Why WordPress Performance Doesn't Start With Optimization
 
Last edited:
WebPrestige

WebPrestige

New Member
#3
#3
Thanks for your reply. I understand your point about PageSpeed. In my case the site is on shared hosting, so I can’t adjust any server settings. The only area I can work on is the frontend, and that’s why I’m checking LCP, CLS and INP. These affect the user experience directly. If you have any tips for improving this under shared hosting limitations, I’d appreciate it.
 
serpent_driver

serpent_driver

Well-Known Member
#5
#5
hellen-charless said:
  • Critical CSS generation through QUIC.cloud
  • Image optimization and WebP/AVIF delivery
  • Edge caching for anonymous users
  • Object caching (Redis or Memcached) if not already enabled
Click to expand...
You're following a typical and widespread narrative. PageSpeed and Lighthouse cannot measure actual loading time and performance. Therefore, server performance measures play no role in PageSpeed and Lighthouse and do not change the score.

LiteCache Rush - WordPress Performance starts with Prevention, not with optimization. Why WordPress Performance Doesn't Start With Optimization
 
Last edited:
WebPrestige

WebPrestige

New Member
#6
#6
Thanks a lot for the detailed and thoughtful feedback, really appreciate it.
You’re absolutely right about the impact of removing unused Newspaper modules — the theme can easily generate a very large DOM and several heavy scripts if everything is enabled. Cleaning that up, combined with ESI for dynamic blocks and Guest Mode, made a noticeable difference on a high‑traffic news site where content updates constantly.
Regarding QUIC.cloud, that’s exactly the next step. Once DNS access is finalized, the plan is to enable the CDN so we can improve TTFB and global delivery, especially for visitors outside Greece. At that point I’ll also test Critical CSS generation and the image optimization pipeline (WebP/AVIF), since both should help stabilize LCP even further during peak traffic hours.
For context, the site is currently on standard shared hosting (PHP 8.2 LSAPI, no Redis/Memcached available), so LSCache is doing most of the heavy lifting. That’s why I wanted to share the results — to show what can be achieved even without root access or a CDN, just by tuning LSCache properly and optimizing the frontend.
Happy to share more configuration details or specific LSCache rules if it’s useful for others in similar setups.
 
You must log in or register to reply here.
Top