Purge Everything ... doesn't

caching

#1

I’ve had this persistent issue of a particular ttf seemingly refusing to be compressed (as reported by webpagetest.org).
Gzip has been confirmed as enabled, including: AddOutputFilterByType DEFLATE application/x-font-ttf.
I finally narrowed the issue to Cloudflare caching.
I’ve executed the following with Cloudflare enabled:
Purge individual file
Pure everything
No change and file still reported as not compressed.

So I disabled Cloudflare and the problem went away with gzip showing 100 score.
With Cloudflare still disabled, I again Purged the individual file and then Purge everything.
Yet as soon as I enable Cloudflare, this file is again reported as not being compressed.

What gives?


#2

Where do you see this?

Can you post a link to the ttf? Orange-cloud it at CloudFlare. And also give the IP of your web server. We can then test with different host file settings to determine the root of the issue.


#3

If you’re orange-clouded then Cloudflare is responsible for gzipping, not the origin* - so purging cache etc will have no effect. We gzip on the fly each time the client requests gzip.

Looking at it - I don’t think we gzip the content-type application/x-font-ttf but we will gzip any of these:

font/ttf application/ttf application/x-ttf

So if you can set any of those content types it should work, or if you want to raise a support ticket with us we could investigate whether we can support this additional content type.

* As a side note, enabling gzip at the origin is a good thing regardless - Cloudflare will always ask for gzip when pulling from the origin so supporting gzip there should save you both time and bandwidth :slight_smile: .


#4

Never faced this problem but you could use a caching on your hosting which affected to purge your cache with Cloudflare.


#5

Thanks. Sorry for the delay in responding as I’ve been traveling.
I have insured that all of the above are set at the origin server.
However, webpagetest.org is still reporting that the file is not being gzipped.

Use gzip compression for transferring compressable responses: 86/100
349.4 KB total in compressible text, target size = 303.2 KB - potential savings = 46.2 KB

FAILED - (81.0 KB, compressed = 34.8 KB - savings of 46.2 KB) - https://brianalawayconsulting.com/wp-content/themes/Divi/core/admin/fonts/modules.ttf

I’ll open a support ticket.


#6

Hi @brian if you’ve changed the content-type at your origin, you’ll need to purge the cache for that URL at least before you will see the changes.


#7

Thanks, I purged the url but it’s still showing as Failed.


#8

Not sure what you mean by “Failed” exactly but if you’re still not seeing gzip encoding are you sure you changed the content type header to match the compatible ones I mentioned? Right now I see application/x-font-ttf being used still which will not be gzipped.

The original URL https://brianalawayconsulting.com/wp-content/themes/Divi/core/admin/fonts/modules.ttf also seems to be returning HTTP 403 from the origin now.


#9

I’m not sure how you’re checking the origin server? I’ve added the above app types to the Apache includes and restarted Apache. “Failed” is being reported by webpagetest.org. However, when I check using gtmetrix.com, it shows a score of 100. So not sure why there is a discrepancy? Using Chrome developer tools, moduless.ttf is reporting a Cloudflare “Hit” (from disk cache).


#10

I am using cURL like this:

If you could try that with your origin IP and paste the output here (redact the origin IP so you’re not listing it publicly) I can take a look over it for you. I just want to make sure the mimetype is being returned for the URLs you’re seeing the issue with.


#11

Hi, @brian did you solve your issue ?