Skip to content

Performance

LSCache hit rate: what good looks like

Learn which pages should hit, which should miss, and how to verify LSCache with a clean logged-out request.

Updated Aug 29, 20264 min read11 reads
LSCache hit rate: what good looks like
What a healthy LSCache hit rate looks like on public pages

A good LSCache hit rate means public pages such as your home page, posts, and category archives return a cache hit for logged-out visitors, while cart, checkout, account, and admin URLs correctly miss. You are not aiming for 100 percent overall, because some pages must stay dynamic. If the home page never hits for an anonymous visitor, a cookie or a plugin rule is usually poisoning the cache rather than LiteSpeed itself failing.

Support tickets often say the cache does nothing and TTFB stays high. In many of those cases the person is testing while logged in, with a page-builder bar open, or after a full cache flush on every comment. A logged-in admin tab is not the right test. A clean logged-out request is.

bash
curl -sI https://example.com | grep -i x-litespeed-cache

Run that twice. The first response may show a miss while the cache is filled. The second should show hit. Variants such as hit,litemage still count as a hit. Empty output means the header is missing, so the plugin may be off, another cache may be in front, or the site may not be on LiteSpeed. A no-cache result or a forced miss on the home page points to a cookie set for anonymous users, a bypass rule that is too broad, or a query string treated as unique.

What good looks like on real URLs

Home, posts, and category archives should hit for logged-out visitors. Cart, checkout, my-account, wp-admin, and wp-login should miss. That pattern is healthy. A perfect hit rate often means the cart was cached too, which can show one shopper another person’s basket. WooCommerce sets cookies that LSCache must vary on or bypass. Those misses protect customers.

Hit rate in the LSCache dashboard is a long average. It can look acceptable while the home page is broken if image crawls pad the number. Trust the response header on the URLs that matter for sales first, then the dashboard. If public HTML is hitting and the site still feels slow, look next at images, JavaScript, or database work on pages that must miss.

How to test without poisoning the result

Use a private window with no extensions and no leftover cart cookie, or use curl as shown above from a machine that is not logged into WordPress. If that request still misses on the home page, the problem is usually a plugin cookie rather than your own session.

Chat widgets, A/B tools, and some page builders set a unique id on first view for anonymous users. That can keep every visit as a miss. Exclude those cookies in the LSCache cookie list, or delay the widget until consent, instead of turning cache off for the whole site. Bypass the bad cookie and keep the hit on the home page.

After a flush or a comment purge

Flushing the entire cache on every comment keeps the home page cold. Purge the changed post and the home page when that is enough. After a full flush, run the crawler politely so the next human visitor gets a hit. Do not start a crawler stampede at the same minute as a backup, because that only hammers the origin you just emptied.

On shared hosting with cPanel and LiteSpeed, AutoSSL and the usual LSCache plugin workflow are enough for this check. You do not need root. Confirm the header on a logged-out public URL, fix cookie or purge rules that force misses on anonymous HTML, and leave intentional misses on cart and checkout in place.

Share

Send this article

Need someone else to do this? Send them the link — the commands are in the article.

Tagged

Was this article helpful?

Be the first to rate this article.