[Resolved] LS not compressing certain files

[Havri]

Hello,

We have some issues with LS GZIP compression on certain CSS files.

In my LS configuration, I have the following setup:

Enable Compression
Yes

Compressible Types
text/*, application/x-javascript, application/xml, application/javascript, image/svg+xml

The problem is that sometimes the response from the server is not GZIP compressed (usually the first request after a period of no requests) and this affects some clients of ours in their google analytics score and other things.

If I switch back to Apache everything work fine and the reply is always GZIP compressed.

Does anyone have this issue as well? Please let me know what other info I should provide to get solve this problem.

 

[NiteWave]

please show the full response headers of the problem .css

 

[Havri]

Hello,

These are the response headers when file is accessed with google chrome:

HTTP/1.1 304 Not Modified
Date: Thu, 22 Oct 2015 12:29:59 GMT
Accept-Ranges: bytes
Server: LiteSpeed
Strict-Transport-Security: max-age=31536000
Vary: User-Agent,User-Agent
Cache-Control: max-age=604800HTTP/1.1 304 Not Modified
Date: Thu, 22 Oct 2015 12:29:59 GMT
Accept-Ranges: bytes
Server: LiteSpeed
Strict-Transport-Security: max-age=31536000
Vary: User-Agent,User-Agent
Cache-Control: max-age=604800

Should I provide the actual link that has this problem?

 

[mistwang]

304 response does not have a response body.So, content-encoding header wont be there.
Try a full reload. let us know the exact URL. we can test as well.

 

[Havri]

The link with the problem is:

http://imlmotoare.ro/wp-content/plugins/js_composer/assets/css/js_composer.css

We have been testing with multiple tools, such as the one below:

http://checkgzipcompression.com/?url=http://imlmotoare.ro/wp-content/plugins/js_composer/assets/css/js_composer.css

Also, sometimes Google PageSpeed Insights shows that GZIP is disabled:

https://developers.google.com/speed/pagespeed/insights/?url=http://imlmotoare.ro/&tab=mobile

Just to give some info about the setup, I have to mention that I don't have any cache configured for this 2-CPU license (I disabled it in trying to figure out this problem). I recompiled Apache using cPanel's Easyapache (PHP 5.5) and then I built the matching LS PHP from the Litespeed plugin in WHM.

 

[NiteWave]

is

js_composer.css

a static file ?

the strange part in the response header:

Vary:User-Agent,User-Agent

if a static .css serverd by litespeed directly, should not have this header

 

[Havri]

Yes, it is a static file. I just ran the "file js_composer.css" command:

js_composer.css: ASCII C program text, with very long lines

 

[NiteWave]

so it's a static file.

need figure out where the response header

Vary:User-Agent,User-Agent

comes from.

it may come from document root's .htaccess
it looks

 wp-content/plugins/js_composer/assets/css/js_composer.css

is inside a plugin ? what's the plugin name ? so I can try it on a wordpress installation.

also you can copy the .css under document root. so we can access and investigate

http://imlmotoare.ro/js_composer.css

to see if the issue exists on above URL as well.

 

[Havri]

I have copied the file as you requested in:

http://imlmotoare.ro/js_composer.css

From what I saw, the file is a part of the WPBakeryVisualComposer.

The problem is that other clients are starting to notice this problem as well. For example, there is also this site that encounters the exact same errors :

The link is:

http://fastsupport.ro/wp-content/themes/Avada/assets/js/main.min.js?ver=3.8.6.1

We've tested with multiple tools, but I'll just send this one:

http://checkgzipcompression.com/?url=http://fastsupport.ro/wp-content/themes/Avada/assets/js/main.min.js?ver=3.8.6.1

Thank you.

 

[NiteWave]

I copied this 800K js_composer.css to another litespeed server, and observed the same behavior.
for small css/js, looks no such issue.

my understanding:
1. when 1st request comes, need gzip the .css, since file size is a bit large, it may take long time.
it may block the requests process ... so litespeed don't wait the complete of gzip, and return the uncompressed .css directly;
2. once .css gzip completes, it stores js_composer.css under "Static GZIP Cache Directory" (https://www.litespeedtech.com/docs/webserver/config/tuning#gzipCacheDir)
3. so next incoming requests to js_composer.css are fetched from cache, and is gzip'ed.

4. for a busy website, this is not an issue at all. most requests to js_composer.css are fetched from cache and compressed.

just read in tips of "Max Static File Size(bytes)": "[Performance] It is not recommended to have the server create/update compressed files for large files. Compressing blocks an entire server process and no further requests can be processed until the compression is completed."

 

[mistwang]

That's due the file size is larger than 400KB. Litespeed does the compression in background to avoid blocking of event loop.
However, the compressed file should be cached until the file has been updated or the cached copy being removed.
Seems server need to constantly compress that file again and again. Is it possible to avoid that.
Please check if the timestamp of that file keep changing? or the Static GZIP cache directory constantly got emptied?

 

[Havri]

Hello,

The timestamps for those files with problems didn't change at all. I'll do some more tests as per your recommendation with the GZIP cache and will keep you posted.

 

[mistwang]

Please update to the latest build mof 5.0.7, the size limit has been increased to 1MB. so the large css file will be always compressed.

/usr/local/lsws/admin/misc/lsup.sh -f -v 5.0.7

 

[Havri]

Thank you for the reply. So from what I understand, the previous limit was 400KB and now is 1MB. Is this correct?

I was already running version 5.0.7 but I ran your command to force the update. I managed to get it working by setting the GZIP cache directory on an SSD drive. The first request was uncompressed but from the second request, the respose was always compressed.

Thank you for your time.