Wordpress LScache Plugin: Slow first view and fonts preloading
Last Updated on: Wed, 15 Apr 2026 00:00:02 Hi, Im in a process of transition from nginx/wp-rocket installation to LS/LScache. Im struggling with one aspect of cache performance and I couldnt find an answer on OpeLiteSpeed forums nor Cyberpanel forums. Actually I was referred from both of of them to LScache developers. Here is what I observer when loading _cached_ paged. I mean, that cache is warmed and header contains x-litespeed-cache: hit. Baseline numbers (LScache off, pur OpenLiteSpeed server): First Byte Start Render FCP Speed Index Last Painted Hero First View 0.675s 1.200s 1.067s 1.655s 1.800s Repeat View 0.445s 0.800s 0.671s 1.108s 1.200s LScache on: First Byte Start Render FCP Speed Index Last Painted Hero First View 2.895s 3.200s 3.032s 3.560s 4.100s Repeat View 0.226s 0.600s 0.488s 0.766s 1.000s WP Rocket on (LScache off): First Byte Start Render FCP Speed Index Last Painted Hero First View 0.245s 0.900s 0.778s 1.310s 1.700s Repeat View 0.194s 0.600s 0.483s 0.970s 1.400s Results of LScache are after 24 hours server was up. This is not production site, so only workload comes from me. The only solution is disable cache plugin, enabling it back, clear all. After this operation results are as expected: First Byte Start Render FCP Speed Index Last Painted Hero First View 0.229s 0.600s 0.417s 0.743s 1.300s Repeat View 0.217s 0.700s 0.484s 0.861s 1.000s Ive seen some people were complaining about same behavior and right now it is a no go for me. Second problem I have is to force preload local fonts. Is there a way to do it (such feature was introduced recently by WP Rocket and is more then welcome by Google Page Speed). I will appreciate any help or hints. This topic was modified 2 years, 4 months ago by oliwkama. I did one more test. Cache cleared and first view is on cold data, second view on cached data. This is something that I can reproduce each time: First Byte Start Render FCP Speed Index Last Painted Hero First View 2.921s 3.300s 3.117s 3.630s 4.100s Repeat View 0.220s 0.600s 0.485s 0.797s 1.000s Compared to results from my previous post, where no cache at all results in TTFB is 0,6s indicates some fundamental problem how much overhead cache mechanism is bringing. Hi, Could you please provide the report number ? You can get it from Toolbox ?> Report , and click send to LiteSpeed Best regards, Hi, Here you are: FJVYFZCR Best! Hi, OK , let me summarize it : You feel high load time when cache is miss (as first few) , but on repeated view , the TTFB is normal where even without cache plugin , the TTFB is still less than cache miss , right ? What if you export your current setting and reset to default ? is TTFB still super long on cache miss ? I only asked because just wanna check if some other functions like JS combine , minify ?etc takes too long , or something else Best regards, Exactly this is what I observe. I didnt think about this approach, but it seems there is a little difference: First view (x-litespeed-cache: miss) First Byte 1,6s Second view (x-litespeed-cache: hit) First byt 0,2s Hi, Could you please try Toolbox ?> Debug ?> Disable all feature set to ON , then check the result ? Best regards, First byte is the same 1,7s and there is no longer x-litespeed-cache header. Second view is 0,9s, so still more then with disabled cache. I disabled all plugins (there just few essential, as this is stage/testing server) and with all disabled times are consistent at 0,4s for both runs (with all features disabled as well) Then started to enable plugin by plugin and First byte was in a range 0,6s. Yoast gave it a boost to 0,9s. Then I re-enabled all features and we are back in a square one: 2,8s first view and 0,2s second view. Finally Ive disabled LScache plugin and result was 0,9s and 0,5s (2nd run) Hi, Well , LSCWP core function uses ob_start to buffer all the output , and prepare it for optimization or other further operations I would assume due to this buffer , it stalls down a bit on my WP vanilla test , without cache plugin , the TTFB is about 80-100 ms , with cache plugin on , first access is about 100-150ms , and when cache hit , its around 50-80 ms , so that pretty much proves my point. and when more plugins or themes in place , it could slows down the process on cache miss scenario Personally I think there is no much necessity to compare the cache miss result , the more important part is when cache hit. Best regards, Overhead is expected in cache miss. I was just trying to figure out, if I misconfigure something badly.
LiteCache Rush: Speed comes from using less, not from doing it faster
Reference