rom174

Okay thanks a lot Frank

The filter is active (.gz are in cache directory but not .br) but I can only see that the files are served as brotli encoded in the response header.
But how can files be served on the fly by CDN/server with brotli compression and not be accessible by autoptimize_filter_cache_create_static_gzip ? Is it a hoster configuration question ?

Ok thank you Frank for your fast support!

Files served as content-encoded: br doesn’t mean it is activated ?
Or it can be active but not necessarily be accessed by autoptimize_filter_cache_create_static_gzip ?

From that point and for you, do you think it is possible/better to :
Disable CDN and serve already compressed files to every places they are requested or to keep CDN and compress files on the fly ?

This means you may receive different results depending on what page the CDN has pulled from your origin server and then cached.

Does the fact I only have (html) pages served is because the CDN doesn’t pull the .html.gz version ?

To go further, is there a way to store/create files the same way it is done for gzip format, I mean for instance : .html.gz -> .html.br, and once this is done, serving it with an .htaccess rule the same way it is done for gzip :
RewriteRule ^(.*)\.html $1\.html\.gz [QSA] -> RewriteRule ^(.*)\.html $1\.html\.br [QSA]

We agree.
Thank you for the support

So, I restored the .htaccess with only the wp minimal setup.
I cleared every cache, retried and it still occurr, this is the cache enabler bottom comment :

<!-- Cache Enabler by KeyCDN @ 07.01.2020 11:08:47 (html) -->

Here is the response header with the default .htaccess :

accept-ranges: bytes
content-encoding: br
content-type: text/html; charset=UTF-8
date: Tue, 07 Jan 2020 10:12:17 GMT
last-modified: Tue, 07 Jan 2020 10:07:13 GMT
set-cookie: SERVERIDxxxxx=xxxx; path=/; max-age=900
status: 200
vary: Accept-Encoding
x-cache-handler: wp
x-cacheable: Cacheable
x-cdn-pop: rbx1
x-cdn-pop-ip: xx.xxx.xx.xxx/xx
x-request-id: xxxxxxxx

Hello @coreyk

Let me know where I can send you the link ?

from what you’ve provided you may just need to completely clear your browser cache

Private nav + cache disabled isn’t enough ?
I did it anyway but still have (html) version served.

If this still doesn’t resolve the issue that you’re experiencing please temporarily disable any page caching layer(s) in front of the Cache Enabler plugin.

The only other caching plugin installed is autoptimize and as the plugin author said it only manages css and js. I did it anyway and the result is still the same : (html) version served.
Linked question : is there a way to verify if the served assets are the ones pre-compressed or compressed on the fly ?

If I can be served with precompressed ressources (cURL command), can I exclude a server-side issue ?

Hello @mateuszgbiorczyk

you have 4 photos uploaded from the /wp-content/uploads/ directory. They are loaded in WebP format, although it also happened to me that they showed up as JPEG (only once).

Well, very interesting that you say it because for me that was the fact there is an “implicite” rewritted URL due to the rewrite rule in htaccess. This is how I was thinking it works, let me know where I am wrong : when the original url is requested, the server first checks if the equivalent webp format exists if it exists, it serves the webp image BUT WITHOUT adding a ressource line to the waterfall, so the original URL of the original image is displayed.
From my side, I always see images coming from /wp-content/uploads/ with .jpg/.png extensions but the type let me know if it is webp or jpg. The weird thing is that 2.5 days later, there are still jpg/png type instead only webp type in the images served by CDN.

However, this looks like some server error. Some built-in cache – it’s hard to say. Please contact your server administrator.

Do you mean the fact the images come from the /wp-content/uploads/ directory instead of /wp-content/uploads-webpc/ directory is a server error ?
Should I really see the images coming from /wp-content/uploads-webpc/ ?

• This reply was modified 5 years, 2 months ago by rom174.

Yes I have used a software to compress it.
It decreased the size from 1400mo to 400mo, so I can say almost for sure every pictures have been optimized.
I have send you an email.

Thanks again

Hello @mateuszgbiorczyk

Thank you very much for your reply !

Where can I contact you to send you the link ?

1/ Just to be sure, what I meant is at each loading/reloading page, I only have 1, 2 or 3 webp images over 23 (for instance) images. All the others are served as jpg, jpeg or png while their webp version well exists. So, what I don’t understand is that the rules are exactly the same for each images but only 1, 2 or 3 of them seems to be affected in each pages.

2/ Yes all the site should be on a CDN, I was trying to check it but it is kindly hard because I don’t manage CDN propagation, it is manage by the hoster. I tried to CURL a random file and I saw it is hosted in Canada, so if the first random file is there, I guess it is ok for the whole site.

I just performed a CURL command and I can see the (html gzip) in the cache enabler bottom comment.
If I check this comment in dev tool, I only have (html), the time is the same.

Would you have an idea of what does it mean ?

If “the decoding fails in the web browser” you’ll see (seemingly) garbled/ random text, it will be _very_ obvious

Haha thanks this is what I imagined ! So nothing about it I could have missed until here.

In order to maybe/possibly override hoster rules, I have added this to the .htaccess file (found here)

AddEncoding gzip .gz

# HTML
RewriteCond %{HTTP:Accept-encoding} gzip
RewriteCond %{REQUEST_FILENAME}\.gz -s
RewriteRule ^(.*)\.html $1\.html\.gz [QSA]

# CSS
RewriteCond %{HTTP:Accept-encoding} gzip
RewriteCond %{REQUEST_FILENAME}\.gz -s
RewriteRule ^(.*)\.css $1\.css\.gz [QSA]

# JS
RewriteCond %{HTTP:Accept-encoding} gzip
RewriteCond %{REQUEST_FILENAME}\.gz -s
RewriteRule ^(.*)\.js $1\.js\.gz [QSA]

# Serve correct content types, and prevent mod_deflate double gzip.
RewriteRule \.html\.gz$ - [T=text/html,E=no-gzip:1]
RewriteRule \.css\.gz$ - [T=text/css,E=no-gzip:1]
RewriteRule \.js\.gz$ - [T=text/javascript,E=no-gzip:1]

  RewriteCond %{REQUEST_FILENAME} -f
  RewriteCond %{THE_REQUEST} (.*)\.html\.gz$
  RewriteRule ^.*$ - [NC,L]

Header set Content-Encoding "gzip" env=is_gzip

With no more success, as the served HTML, JS and CSS files are still served as non pre-compressed files.

@coreyk

Can it be linked to the CDN solution included with by my hosting providers ?

@optimizingmatters thank you for helping

Just before I see your answer I tried to disabled (was enabled) it with no success so I re-enabled this option because I am not sure the decoding fails as it well serves compressed files on the fly.

What are the ‘signs’ of a failed decoding ? Everything is broken ?

@coreyk

Yes I also have Autoptimize but except this pre-compression issue it works and I have read that AO and CE have been updated to co-exist better.

I have disabled AO for the test and it is still retrieving html not compressed.

Could you provide me with the correct .htaccess rules or if you have a link to advise it would be nice ?

Thank you