Support » Plugin: LiteSpeed Cache » Slow CSS/JS processing

  • Resolved kokers

    (@kokers)


    Hi,

    I’ve recently had a pleasure working on LiteSpeed server and finally got a chance to test your plugin. And! just yesterday you released version for non-LiteSpeed servers (whaaaat?), so I’ve compared test results.

    And I have one question about minify and combine option. Should it slow down website so much during first load and why it’s still slower to load cached files when comparing different plugins?

    All my results are based on pingdom test from Sweden location.

    LiteSpeed SSD server, HTTP/2, SSL —————

    Because it’s http/2 I’ve minified both css and js files but combined only js (http/2 still got some limits)

    For example, this is an average “wait” time for css/js files on my LiteSpeed server after Purge All action https://monosnap.com/file/hLK9xRaKv3Lj26qyeojL3zORpceoZg
    For second run it’s <200ms

    During that test I’ve encountered probably a bug. When theme was including style.css with only theme comment data like, theme name, author and so on, after minifying the file was empty. That caused this resource to be processed over and over again which was slowing down whole website. https://monosnap.com/file/zbjUSJA9ZMxVUOd4J1MBgT8qXNtr5S Loading “wait time” of that resource (empty css file) took almost 2s on each refresh. So I’ve excluded this file from processing and tested again. Btw, this isn’t uncommon for theme developers to create empty style.css file for WP with only a comment. Not sure why they enqueue it in wp_enqueue_style, but it happens.

    After clearing cache website loaded in 13.92 s, and wait time for css/js resources was between 5-10s
    Second run was around 1s to load, and wait time for css/js 120 – 160 ms

    I’ve compared this with WP Fastest Cache and Minify+Combine+Refresh
    First run loading time was 4.04 s, document wait time was 3.2 s, and resources wait time was 45-130 ms
    second run website loaded in 1.13 s, document wait 85ms, css/js wait time 44-130 ms

    So cached result is somewhat comparable, yet during cache creation loading time was waaaay longer with LiteSpeed Cache.

    For second website also on LiteSpeed server first run was 7.7s (this site have less resources than first one) with wait time 3-4.8s for css/js, and <1s with second run. css/js wait time ~120ms

    If I disable css minify/combine part for resources then after cache clear the loading time is 1.38s

    Non LiteSpeed SSD server, HTTP/1, SSL ———————

    Then I’ve tested third website with new update, not a LiteSpeed server and without HTTP/2 so this will is a bit different, but the timings for processing css/js files is still very long and are long even after creating cache files.

    Setting to minify but not combine:
    First run wait time for css is 1.5-3.5s
    Second run wait time is still long, 0.6-1.2s even tho it should load static files (they are created I’ve checked)
    Document wait time is between 1.1s-1.3s for both tests

    Because on that server theres no support for http/2 I’ve turned on combine part.

    First run, document wait time increased to 2.8s comparing to combine OFF setting, and css/js wait time was 1s.
    Second run, document wait time 1.3s, css 850ms, js 1.4s
    Third run (just in case), document 1.8s, css 773ms, js 2.69s wait time.

    So it looks like, even though files are created, they are not served as static resources. Not sure if in this case it’s because it’s new release not fully tested with non litespeed servers, but overall processing CSS/JS files via LiteSpeed plugin takes very long time. In theory css/js files won’t change that often, but still. That’s a lot of time imo.

    Switching back to Fast Velocity Minify
    First run, document wait time 3.9s, css and js wait time ~ 40ms
    Second run, document wait 1.1s, css/js ~ 60ms
    third run, document 1.05s, css/js ~55 ms

    —-

    Overall the caching part on LiteSpeed server in my tests is great. The minify combine part not so much. I was hoping to use one plugin for website optimizations, but so far it looks like we need to still use different plugins for caching and css/js processing.

    So returning to my question. Is this LiteSpeed plugin, or server configuration. Comparing with other plugins, it looks more like plugin issue. Is this something that can be improved in the future?

Viewing 7 replies - 1 through 7 (of 7 total)
  • Plugin Support LiteSpeed Lisa

    (@lclarke)

    Wow, @kokers, thank you for compiling and sharing all of those useful details!

    It’s going to take a little while to read over your results carefully and digest them. In the meantime, we’ll take a closer look at that possible bug- thanks for that.

    Lisa

    Thread Starter kokers

    (@kokers)

    @lclarke if links to pingdom reports would be more helpful than just numbers, find me on your community slack channel and I’ll be happy to pass them via PM.

    Overall, CSS/JS optimization isn’t great.

    Also this post was held for moderation. Do you have by any chance information as Plugin Support why this happened?

    Plugin Support LiteSpeed Lisa

    (@lclarke)

    Great! We will look for you on Slack.

    We don’t have the ability to moderate WP forum posts, so whatever the reason, that was a WordPress thing.

    Plugin Support Hai Zheng⚡

    (@hailite)

    Thanks for your detailed feedback. Very helpful.

    The reason empty js/css can cause 2s load for each request is the current version set it to nocache if found failed to generate optimized data from source files.

    That is a good catch. Looks like we need to cache them. This will be in next release.

    Thanks again.

    Plugin Support Hai Zheng⚡

    (@hailite)

    The fix is in https://github.com/litespeedtech/lscache_wp/commit/bb7633d8cd7bd76aae8d7a264c6772eae72faa4a

    You can just use the changes to litespeed-cache/inc/optimize.class.php

    • This reply was modified 3 years, 10 months ago by Hai Zheng⚡.
    Thread Starter kokers

    (@kokers)

    Awesome news :o) I’ve already got github notification. Thanks for that.

    Although the problem with slow minifying still exists. I’ll try to prepare case study for that with more “readable” data for you during weekend.

    Thread Starter kokers

    (@kokers)

    For anyone interested in the solution for slow css/js processing, we’ve talked with Hai on slack, and there will be some changes that address this issues in next release.

    Thanks team.

Viewing 7 replies - 1 through 7 (of 7 total)
  • The topic ‘Slow CSS/JS processing’ is closed to new replies.