Thank you for taking the time to visit. I've been attempting to tackle this issue on my own, but it seems to be a bit overwhelming for me once again.
THE SCENARIO...
I have my website live on a shared hosting platform. As I delved into compressing my numerous cms-generated js and css files to improve PageSpeedInsights performance, I discovered that my hosting provider does not have mod_gzip or mod_deflate installed. Instead, they have ZLIB. After some research, I found the typical php append solution unsatisfactory. However, I did stumble upon a few lines of htaccess code that worked like a charm:
AddHandler application/x-httpd-php .html .htm .php .js
php_flag output_buffering On
php_value output_handler ob_gzhandler
php_flag zlib.output_compression Off
I verified its functionality using GIDZipTest. Everything was running smoothly and I was thrilled.
Unfortunately, when I added .css to the AddHandler List, my website completely crashed.
I attempted to employ the php solution with ob_gzhandler specifically for css files, but it failed to function at all. It simply did nothing.
POTENTIAL SOLUTION? (NOT SO MUCH)
I manually condensed all the css files and uploaded a css.gz version of each one, serving them with
RewriteCond %{HTTP:Accept-encoding} gzip
RewriteCond %{REQUEST_FILENAME}\.gz -s
RewriteRule ^(.*)\.css $1\.css\.gz [QSA]
RewriteRule \.css\.gz$ - [T=text/css,E=no-gzip:1]
This approach also worked effectively.
QUERIES!
- What specifications are required for css compression to function as intended? It feels like I am missing out on some crucial conversion steps...
- If I serve my manually condensed .css.gz files to a client, will they undergo additional compression?
- Would this result in further reduction in file size or should I simply stick to the manually served versions and disregard Google PageSpeed?
(GIDZipTest still presents potential scenarios even for the condensed files, displaying impressive numbers. I am intrigued by that...)
Thank you in advance for any feedback provided.
Warm regards
Marian