Speed of loaded page slower then normal .htaccess solution

[gundestrup]

Loadtime "pingdom speedtest" 650-627ms vs 350-299ms
(even on multiable reload).
`
#

CacheEnable public

RewriteEngine On

RewriteCond %{REQUEST_METHOD} ^HEAD|GET$

RewriteCond %{HTTP_HOST} ^lungekursus.dk|a2.lungekursus.dk|www.lungekursus.dk [NC]

RewriteCond %{HTTP_COOKIE} !loginuser

RewriteCond %{ORG_REQ_URI} !^/index.php$

RewriteCond %{ORG_REQ_URI} !administrator

RewriteCond %{ORG_REQ_URI} (.php|.html|.htm|.feed|.pdf|.raw|/[^.]*)$ [NC]

RewriteCond %{QUERY_STRING} !nocache

RewriteCond %{REQUEST_URI} !^/[0-9]+..+.cpaneldcv$

RewriteCond %{REQUEST_URI} !^/.well-known/acme-challenge/[0-9a-zA-Z_-]+$

RewriteCond %{REQUEST_URI} !^/.well-known/pki-validation/[A-F0-9]{32}.txt(?:\ Comodo\ DCV)?$

RewriteRule .* - [E=Cache-Control:max-age=1]

#
##plugin Litespeed code

CacheLookup on
RewriteEngine On
RewriteRule .* - [E=esi_on:1]

`

[gundestrup]

very stange, reenabled the code you provide, now load time is 299ms? (pingdom speedtest - test server sweden) (jotcache cleared, litespeed cache clered, joomla cache cleared).
Next test: load time is 4200ms, (pingdom speedtest - test server sweden).
Next test: 800ms

[jacksonlst]

What do you means: "reenabled the code you provide" ? Do you means to use joomla cache plugin?

Cache TTL seems too short:

RewriteRule .* - [E=Cache-Control:max-age=1]

your rewrite rule only cache file for 1 second, you should change it to something longer, otherwise it may not be served from cache.

RewriteRule .* - [E=Cache-Control:max-age=120]

[gundestrup]

I changed the age to 360, same problem.
Regarding the code
The first setup is LScaching via .htaccess, code via a2hosting.
When I disable that code and enable the .htaccess you provide to user the code via the github plugin, thi i the result. (very unstable load times).

[jimhill10]

Question, does anyone know which server directory the cache files are being stored? My staging server is on the same one as production and I am hoping the files are not being sent to the usual "lscache" which would mix with production. My staging server is now properly reporting a "hit" for Lscache. Took a few minutes are installation for this to show up, was showing "miss." I have some differences in my two sites. Production is using JCH Optimize and a CDN. My dev site with the new cache plugin (ordered last) is using neither.

Ran some tests on webpagetest.org. Results were similar except that the first byte time increased by 2 seconds for the site with cache plugin. Per bytecheck.com the TTFB tests are:
-Original site with htacess cache rule: 475 ms, 370ms of which is for the SSL, 31 ms for waiting.
-Site with the new plugin: 3263 ms, with 475 ms for SSL and 2671 for waiting.

Loading time per GtMetrix / Pingdom:
-Original site, 2.0 seconds / 2.0 seconds
Pingdom result
-Site with the new plugin: 6.2 sec / 3.4 sec
Pingdom result

[jacksonlst]

Yes. The first visit will be "miss", then you should see "hit" at the second visit. You should look for "X-LiteSpeed-Cache: hit" to ensure the cache is actually working before you run any test.

[jacksonlst]

Also don't mix the rewrite rules based cache enabling method with plugin-based cache enabling method.
and also should disable other Joomla full page cache plugin first before enabling LiteSpeed cache plugin.

The cache files are stored as files on disk and cache root will be set at LSWS or apache conf.
https://www.litespeedtech.com/support/wiki/doku.php/litespeed_wiki:cache#prerequisites
Configure Cache Root section.

[jacksonlst]

for performance issue originally reported, mainly due to some setup issue. there is a ticket logged in our support ticket system. We have obtained the login for the server on that ticket. We are helping to fix the configuration issue, afterward, we will show the test figure here for the real performance. We will also run some benchmark tests and show you the result.

[jimhill10]

I have a testing site using the Litespeed plugin which in every other way replicates production which uses htaccess directives for Litespeed cache. Both sites use JCH Optimize with a CDN. I am having an issue with a long first byte time on the test site. It is a full 2 seconds longer than production. Other than that the page load time is similar. See this test:
Bytcheck testing site
Bytecheck production

Here are some test results on the same page (Pingdom / Webpagetest / Gtmetrix in seconds

Test Server: 3.7 / 6.2 / 6.0
Production Server: 3.2 / 3.5 / 4.0

Second, can you clarify what other cache/compression directives you are using? We have a variety of directives in our production site. I took them out of the test site in order to try to solve the long TTFB. Here are the ones in place on production:

• mod_gzip directives.
• mod_deflate directives (AddOutputFilterByType DEFLATE text/html, etc. added by JCH Optimize)
• Etag Optimization directives. Expires ByType ...(added by JCH Optimize)

Here is our htaccess file if you are interested.

[gundestrup]

There is still no solution
they have currently done the following:

We also disabled some conflict plugins in joomla administrator panel, we
disabled "Recache" plugin, dsabled "JotCache" plugin, disabled "System -
Page Cache" plugin, disabled "System - Regular Labs - Cache Cleaner" plugin

I have copyed my production server, and given them full access, but I cannot report any progress.
Last login from the firm was 24h ago, form spain and USA...

So I guess it's more difficult then a simple fix.

When I know more, I or the firm will update

[jimhill10]

I am trying to track down what is causing my long TTFB on my dev site while production is almost zero. I will spend some time on this to disable every plugin as well as use the Joomla debug to analyze queries and see what is taking so long.

[jimhill10]

I have 1.0.1 running in production and I think that this is actually faster than the former htacess directive method. I am interested if others are seeing the same thing. I am using a few values to match a regex in the exclusions list, and a bunch of modules in ESI mode including all the Rsforms. So I am not seeing a repeat of what I saw on our dev site with this issue.

[gundestrup]

Closing, after upgradring to 1.20 of plugin, and duing my speed testing it's no longer a problem.
I suggest upgrading to newest version of plugin