im trying to learn about browser caching techniques.
all is going good so far, apart from one bit im stuck on.
when i run an audit on google chrome. i get
Leverage browser caching (1)
The following resources are explicitly non-cacheable. Consider making them cacheable if possible:
www.noelie.localhost.com/
i fixed the css and javascript with
<FilesMatch "\.(css|js|png|jpg)$">
Header set Cache-Control "max-age=31536050, public, cache"
</FilesMatch>
how do i cache the homepage www.noelie.localhost.com.
thank you for your time. noelie
Related
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.
Lately I've become somewhat obsessed with page speed optimization and I wanted to find out can CMS caching mechanism (For example Joomla cache), Gzip compression and Cloudflare work all together in perfect harmony?
I understand how each system works by itself (more or less), but I don't understand would they work together. Is it even recommended to use all of them at once?
If I use cloudflare do CMS cache and Gzip even matter?
P.S What other tools do you use?
can CMS caching mechanism (For example Joomla cache), Gzip compression and Cloudflare work all together in perfect harmony?
Yes, plus they all do slightly different things.
Cloudflare caches the static content, eg images and stylesheets. Fresh page HTML is still downloaded by every visitor on every page.
Gzip compression comes into play both with Cloudflare and your server. By default Cloudflare automatically compresses content passing through it's system, Files not passing through Cloudflare can be compressed by your server, Caching and gzip compression by htaccess , though since you are using Joomla, the easiest way to enable this is from
the control panel > system > global configuration > server > Gzip Page Compression.
This will decrease download times for the page HTML and the dynamic content produced by Joomla.
Using Joomla cache will typically reduce page load times because instead of Joomla using modules and plugins to recalculate the dynamic page content everytime for every visitor, it will simply use the saved cache content. You can cache Joomla content by page, by module or by plugin, here's one good explanation of the differences.
It's worth spending some time testing with a tool like WebPageTest to find the best Joomla cache option for your specific site. I've sometimes had significant savings with this.
It's makes sense to have all 3 working on your site, it will reduce server load and speed up page display.
Good luck!
Just a heads up. Some content in certain browsers can experience byte range request issues if you have gzip enabled while using cloudfare.
For instance, depending on server, Safari will (most likely) not play mp4 video served through cloudfare and gzip enabled server. Gzip can interfere with byte-range separation of requests.
I ran into this issue before and figured I would share in case anyone runs into any of these issues.
If you want to have gzip enabled, but experience issues with certain files, you can disable gzip for those specific files in .htaccess by adding this:
<IfModule mod_headers.c>
<FilesMatch "\.mp4$">
RewriteRule ^(.*)$ $1 [NS,E=no-gzip:1,E=dont-vary:1]
</FilesMatch>
Just replace .mp4 with file type if issues with any others.
I help maintain several Wordpress-based websites that publish news and reference information.
We have been working hard to make pages at the websites load as fast as possible.
One of the things we've done is implement very long "max-age" times in the "cache-control" http headers for most of our static files, such as images and css files.
The particular cache-control setting we're using is "public, max-age=31536000". 31,536,000 seconds is 365 days.
The upside is that this setting does, in fact, cause the static files to be cached as visitors browse through different pages of our sites.
But here's the rub. This cache-control setting doesn't do much for us across browser sessions. Even though the setting is supposed to tell the browser "cache this file for an entire year", if a visitor to our site shuts down their browser, then starts it up just five minutes later and comes back to our site, the browser insists on re-loading all the static files, even though it still has them in its cache.
I've checked this carefully in Firefox, viewing the headers with Live HTTP Headers. But I can also qualitatively see the same thing happening in other browsers.
Apparently, browsers insist on re-loading all content for a website if the content hasn't been loaded once during the current browser session.
So ... Is there any way we can "politely suggest" to browsers that they always load cached content from the cache, even if the browser hasn't been to our site during the current browser session?
Check the ETag, Expires, and Last-Modified headers as well.
You need an Expires header, and sometimes ETag and Last-Modified can defeat caching.
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/
It seems that IE6 ignores any form of cache invalidation sent via http headers, I've tried setting Pragma to No Cache and setting Cache Expiration to the current time, yet in IE6, hitting back will always pull up a cached version of a page I am working on.
Is there a specific HTTP Header that IE6 does listen too?
Cache-Control: private, max-age=0 should fix it. From classic ASP this is done with Response.Expires=-1.
Keep in mind when testing that just because your server is serving pages with caching turned off doesn't mean that the browser will obey that when it has an old cached page that it was told was okay to cache. Clear the cache or use F5 to force that page to be reloaded.
Also, for those cases where the server is serving cached content it you can use Ctrl+F5 to signal the server not to serve it from cache.
You must be careful. If you are using AJAX via XMLHttpRequest (XHR), cache "recommendations" set in the header are not respected by ie6.
The fix is to use append a random number to the url queries used in AJAX requests. For example:
http://test.com?nonce=0123
A good generator for this is the UTC() function that returns a unique timestame for the user's browser... that is, unless they mess with their system clock.
Have you tried setting an ETag in the header? They're a pretty reliable way to indicate that content has changed w3c Spec & Wikipedia
Beyond that, a little more crude way is to append a random query string parameter to the request, such as the current unix timestamp. As I said, crude, but then IE6 is not the most subtle of beasts
see Question: Making sure a webpage is not cached, across all browsers. How to control web page caching, across all browsers? I think this should help out with your problem too.
Content with "Content-Encoding: gzip" Is Always Cached Although You Use "Cache-Control: no-cache"
http://support.microsoft.com/kb/321722
You could also disable gzip just for IE6
A little note: By experience I know that IE6 will load Javascript from cache even if forced to reload the page via Ctrl-F5. So if you are working on Javascript always empty the cache.
The IE web developer toolbar can help immensely with this. There's a button for clearing the cache.