I have tried everything and I am stumped so I will appreciate some help. I have an image on S3 with a cache-control of 'public, max-age=31536000'. The S3 is set up as a static website and I plan to serve it via Cloudflare. However, Cloudflare does not seem to cache the images. Here is an example URL:
https://media-dev.slpht.net/L32JrnoWRgD4xDYBuaEkYzpC
Inspecting it, I see
cache-control: public, max-age=31536000
cf-cache-status: DYNAMIC
I think if it says DYNAMIC, that means that it is not caching. I am also getting 200 OK every time I refresh the page and I am expecting a 304?
Leaving the question and answering it in case it helps someone. If it does not, please remove this post.
It turns out that I have "Disable cache" on my Chrome browser on. When I turn it off, refreshing the page returns a 304.
Related
I just learned and implemented varnish reverse proxy to increase my website speed.
Everything works fine but something minor bothers me.
For some reason, when I check page TTFB for the first time, I get .999s, however, when I rerun the test the number drops to .237s.
I use the following website to check TTFB:
https://www.webpagetest.org
and my website is:
https://www.findfestival.com/
It makes me wonder if the first request to the website hits the cache. When I use curl I can see x-varnish but still it's strange that first time clicking on links are slower compared to the second time clicking on them. (specifically on mobile)
Can you please help me understand why first time Varnish cache doesn't hit?
This is my default.vcl is:
Thanks,
PS, I have seen this post and already tried the solution with no luck!
Varnish Cache first time hit
Seeing how you have X-Mod-Pagespeed in your headers and minimalistic VCL, the conclusion is that you need to take a look at Downstream Caching and make sure that PageSpeed would not send Cache-Control: max-age=0, no-cache which breaks Varnish caching for the most part.
In my own experience, Pagespeed does not play well with Varnish even with downstream caching configuration applied.
It "loves" to send the aforementioned header no matter what. Even if you manage to turn this behaviour off, it results in PageSpeed's own assets not having proper Cache-Control headers plus a few more interesting issues like causing Varnish "hit-for-pass" when rebeaconing has to take place - which is really bad and breaks caching further.
Also have a look at possible configurations. You might want to put PageSpeed at your SSL terminator level (option #1) - that way you don't need Downstream Cache configuration and PageSpeed will be "in front" of Varnish.
I am trying to get some html pages to be cached, the same way images are automatically cached via CloudFlare but I can't get CloudFlare to actually hits its cache for html.
According to the documentation (Ref: https://support.cloudflare.com/hc/en-us/articles/202775670-How-Do-I-Tell-CloudFlare-What-to-Cache-), it's possible to cache anything with a Cache-Control set to public with a max-age greater than 0.
I've tried various combinations of headers on my origin Nginx server without success. From a simple Cache-Control: public, max-age=31536000 to more complex headers including s-maxage=31536000, Pragma: public, ETag: "569ff137-6", Expires: Thu, 31 Dec 2037 23:55:55 GMT without any results.
Any ideas to force CloudFlare to serve the html pages from their cache?
PS: I am getting the CF-Cache-Status: HIT on the images and it works fine but on the html pages nothing, not even CF-Cache-Status: something. With a CloudFlare page rule for html pages, it seems to work fine but I want to avoid using one, mainly because it's too CloudFlare specific. I am not serving cookies or anything dynamic from these pages.
It is now possible to get Cloudflare to respect your web servers headers instead of overriding them with the minimum described in the Browser Cache TTL setting.
Firstly navigate to the Caching tab in the Cloudflare dashboard:
From here you can scroll down to the "Browser Cache Expiration" setting, from here you can select the "Respect Existing Headers" option in the dropdown:
Further reading:
Does CloudFlare honor my Expires and Cache-Control headers for static content?
Caching Anonymous Page Views
How do I cache static HTML?
Note: If this setting isn't chosen, Cloudflare will apply a default 4 hour minimum to Cache-Control headers. Once this setting is set, Cloudflare will not touch your Cache-Control headers (even if they're low or not at all set).
I stumbled on this too. From the page it says
Pro Tip: Sending cache directives from your origin for resources with extensions we don't cache by default will make absolutely no difference. To specify the caching duration at your origin for the extensions we don't cache by default, you'd have to create a Page Rule to "Cache Everything".
So it appears that you do have to set a page rule to use this for files that CloudFlare doesn't cache by default. This page describes this in more detail,
https://blog.cloudflare.com/edge-cache-expire-ttl-easiest-way-to-override/
That said it still didn't work for me and appears not to be supported. After contacting their support they confirmed this. Respect Origin Header has been removed from all plan types. So if you have no page rules they will respect the origin header.
This doesn't help for hitting their edge cache for html pages however. To that you have set up a page rule. Once that is done you can, I believe, set your max-age as low as your plan allows. Any lower and it gets over-written. That is to say, with no page rule you could say Cache-Control: max-age:30 and it would pass through. With a page rule that include edge caching your max-age then becomes subject to the minimum time your plan allows even if the page rule doesn't specify browser cache.
The CF documentation is very unclear. Go into "Page Rules", and define a rule that turns on caching, based upon wildcards -- and then it will work.
We have a web application.
Until now we had no real cache handling strategy.
When we had a new version of certain JavaScript files, we instructed our users to clear their browser cache.
Now we want to change this.
Up to this date our starting page was "start_app.html".
In our effort to implement our cache busting strategy we want to ensure that the browser will NOT cache our starting page.
We will change the extension from ".html" into ".php".
It seems that the browser has an array of extensions, when he ALWAYS fetches a fresh copy from the web server, like "php", "asp", and so on.
Is this true and which extensions are these?
Thanks alot in advance
Please don't rely on incorrect browser behavior to not cache your page. Instead, use this header:
Cache-Control: no-cache, no-store
This page has all the details as to why that header will do what you want.
I spent a few hours on a AWS CloudFront problem, hope someone can save me :D
When i load the site homepage, for every assets i get (on each reload):
X-Cache:Miss from cloudfront
When i try to open an asset in another tab, i then got the correct behavior (miss on first call, then hit on each reload). Same with curl requests.
I reload my home and inspect the same asset, i get:
X-Cache:Hit from cloudfront
with a similar age as in the tab.
Then i reload my homepage and inspect the same element again:
X-Cache:Miss from cloudfront
:'(
And from this point, when i reload the asset in the other tab, i get a miss...
Any idea ?
Thanks,
Jérémy
After many tests on Apache configuration and CloudFront configuration, i found that cookies where causing this behavior.
Some cookies used by tracking systems change their values on each call and then cloudfront do not cache the request.
To solve it, create a custom behavior for each type of path (backend calls, assets, etc.) and create a whitelist of cookies that you really need to forward in it.
i hope this will help someone.
Thanks #AlexZakharenko and #BruceP for your replies ;)
After running the YSlow plugin on a site, I saw that one of the recommendations was to add far future expires headers to the scripts, stylesheets, and images.
I asked a different question about how to set this up in IIS, but I am actually just curious about how each browser behaves.
I have read that IE will cache items per browsing session, so once you reopen the site after closing the browser, it will need to reload all of the content. I believe that Firefox will go ahead and set a expiration date on its own. I have also heard that IE does not cache at all when connecting over HTTPS. I am not sure if these are at all accurate, though, and was wondering if someone could clear up any misconceptions I may have. Thanks!
You are right about Firefox setting its own expiration date. See the second item in this blog post:
http://blog.httpwatch.com/2008/10/15/two-important-differences-between-firefox-and-ie-caching/
IE, like Firefox, can cache HTTPS based content. However, you need to set Cache-Control: public for persistent caching across browser sessions in Firefox. See Tip #3 in this blog post:
http://blog.httpwatch.com/2009/01/15/https-performance-tuning/