For my website Google PageSpeed Insights recommends to change expiration values for some cacheable resources like .css, .js,.svg ,google api ,siteimprove .Is it feasible to set the expiration values for the above files? If yes,then what configuration will be required for that?
Enabling browser caching for these items is not something which normally relates directly to Sitecore as they are typically static files within your webroot, not served by Sitecore. This question How to configure static content cache per folder and extension in IIS7? should help you with configuring the folders in your webroot to have the correct cache headers.
Tip: these changes would be applied to the web.config file and I would suggest using web.config transforms to apply those changes to the web.config rather than modifying it directly.
I am creating a mobile singlepage web app using jquery mobile. The webapp includes a number of javascript files and a number of css files. I have written a deploy script that concatenates and minifies js and css files, and now I am wondering whether I should inline the concatenated js and css directly in the HTML file - please note that I am talking about a singlepage app here (I know that this would be a bad idea in a traditional web 1.0 app with dynamically generated HTML). I am also using appcache/manifest file to cache the singlepage app so that subsequent access to the web app will be served from the cache, so it is the initial load time that is my primary concern.
When I inline everything (jquery, jquery mobile etc.), my 7kb HTML file increases to 350kb (100kb zipped) but now everything can be loaded in a single request.
But am I missing some other benefits such as parallel downloading of js files - and would it therefore be better to not inline the css and js, but instead just concatenate all js and css to a single js file and a single css file and then fetch each of them in separate requests?
Are there any limits regarding file size that I should be aware of? Maybe caching in network routers works better with smaller file sizes or whatever?
So my question boils down to whether it is a good idea to inline everything when making singlepage mobile web apps?
The answer to how much should be concatenated and how much should be inlined varies depending on a number of conditions. The final answer is you should do A/B testing and find what works best for you. From what you describe I recommend you definitely NOT inline 350K of CSS & JS. If you do this then any change to the HTML or JS or CSS requires downloading the entire payload. Instead, compartmentalize those changes and forced updates by keeping HTML, JS, & CSS as separate requests. You could do dynamic | inlining to make the first response fast but leverage (app or localStorage) cache for subsequent requests, but that's going to get complicated when coupled with app cache (because the HTML doc is saved to app cache). Otherwise, just keep them separate, save each resource to app cache, and update individual resources as needed.
I would not recommend inlining everything into the html if your webapp could be accessed from different urls with different querystring.
Example :
http://webapp.com/?fb_token=fdsf
http://webapp.com/?referer=bla
http://webapp.com/?tracker=toto
Each of those will add a master copy in the appcache (you can veryfy it by looking at chrome://appcache-internals/ in chrome). You then risk to reach the quota limit for appcache in term of cache. Furthermore on appcache update, the browser goes through its appcache entry list and ask a fresh copy of it.
A good compromise that i am following for mobile device & appcache , is to keep the html tiny and then have one big css (containing base 64 inlined images) and one js file.
FYI, there is currently a quota limit on the size on the sum of all your listed resources in appcache in the order from 5MB to 25MB (25 being the new iOS6 limit)
-seb
I have a specific Adobe CQ5 (5.5) content template that authors will use to create pages. I want to exclude any page that is created from this template from the dispatcher cache. As I understand it currently, the only way I know to prevent caching is to configure dispatcher.any to not cache a particular URL. But in this case, the URL isn't known until a web author uses the template to create a page. I don't want to have to go back and modify dispatcher.any every time a page is created--or at least I want to automate this if there is no other way. I am using IIS for the dispatcher. The reason I don't want to cache the pages is because the underlying JSPs that render the content for these pages produce dynamic content, and the pages don't use querystrings and won't carry authentication headers. The pages will be created in unpredictable directories, so I don't know the URL pattern ahead of time.
How can I configure things so that any page that is created from a certain template will be automatically excluded from the dispatcher cache?
It seems like CQ ought to have some mechanism to respect HTTP response/caching headers. If the HTTP response headers specify that the response shouldn't be cached, it seems like the dispatcher shouldn't cache it--regardless of what dispatcher.any says. This is the CQ5 documentation I have been referencing.
I don't know about the IIS verson of the Dispatcher, but certainly with the Apache module if you add a custom HTTP header "dispatcher: nocache" it will not cache the page in the Dispatcher. You would need to change the code to add this, which would be something like:
request.setHeader("Dispatcher", "nocache");
It might also work as meta tags in the html, but I've not tried this.
This is documented here: http://dev.day.com/content/kb/home/Dispatcher/faq-s/DispatcherNoCache.html
You might use cache control tags in the template's head. See info on PRAGMA and Cache-Control meta tags here: HTTP Cache- Control.
Running my site on IIS7 and looking to improve my Yslow rating. Working with asp.net.
I am able to cache static resources in the web.config but is it possible to the following also:
Set the etag on the resources eg. javascript, images, css files etc
Add expires header to the above static resources
Set gzipping on components
Previously I use to use httphandlers to achieve the above but if its possible to set it up in the web.config it would be great.
As far as I'm aware you cannot set your etag values in your web.config and have it work.
Check out How do I remove eTag headers from IIS7? for more information. You can try setting a blank etag via IIS however to remove it completely.
If I understand correctly, a broswer caches images, JS files, etc. based on the file name. So there's a danger that if one such file is updated (on the server), the browser will use the cached copy instead.
A workaround for this problem is to rename all files (as part of the build), such that the file name includes an MD5 hash of it's contents, e.g.
foo.js -> foo_AS577688BC87654.js
me.png -> me_32126A88BC3456BB.png
However, in addition to renaming the files themselves, all references to these files must be changed. For exmaple a tag such as <img src="me.png"/> should be changed to <img src="me_32126A88BC3456BB.png"/>.
Obviously this can get pretty complicated, particularly when you consider that references to these files may be dynamically created within server-side code.
Of course, one solution is to completely disable caching on the browser (and any caches between the server and the browser) using HTTP headers. However, having no caching will create it's own set of problems.
Is there a better solution?
Thanks,
Don
The best solution seems to be to version filenames by appending the last-modified time.
You can do it this way: add a rewrite rule to your Apache configuration, like so:
RewriteRule ^(.+)\.(.+)\.(js|css|jpg|png|gif)$ $1.$3
This will redirect any "versioned" URL to the "normal" one. The idea is to keep your filenames the same, but to benefit from cache. The solution to append a parameter to the URL will not be optimal with some proxies that don't cache URLs with parameters.
Then, instead of writing:
<img src="image.png" />
Just call a PHP function:
<img src="<?php versionFile('image.png'); ?>" />
With versionFile() looking like this:
function versionFile($file){
$path = pathinfo($file);
$ver = '.'.filemtime($_SERVER['DOCUMENT_ROOT'].$file).'.';
echo $path['dirname'].'/'.str_replace('.', $ver, $path['basename']);
}
And that's it! The browser will ask for image.123456789.png, Apache will redirect this to image.png, so you will benefit from cache in all cases and won't have any out-of-date issue, while not having to bother with filename versioning.
You can see a detailed explanation of this technique here: http://particletree.com/notebook/automatically-version-your-css-and-javascript-files/
Why not just add a querystring "version" number and update the version each time?
foo.js -> foo.js?version=5
There still is a bit of work during the build to update the version numbers but filenames don't need to change.
Renaming your resources is the way to go, although we use a build number and embed that in to the file name instead of an MD5 hash
foo.js -> foo.123.js
as it means that all your resources can be renamed in a deterministic fashion and resolved at runtime.
We then use custom controls to generate links to resources at on page load based upon the build number which is stored in an app setting.
We followed a similar pattern to PJP, using Rails and Nginx.
We wanted user avatar images to be browser cached, but on an avatar's change we needed the cache to be invalidated ASAP.
We added a method to the avatar model to append a timestamp to the file name:
return "/images/#{sourcedir}/#{user.login}-#{self.updated_at.to_s(:flat_string)}.png"
In all places in the code where avatars were used, we referenced this method rather than an URL. In the Nginx configuration, we added this rewrite:
rewrite "^/images/avatars/(.+)-[\d]{12}.png" /images/avatars/$1.png;
rewrite "^/images/small-avatars/(.+)-[\d]{12}.png" /images/small-avatars/$1.png;
This meant if a file changed, its URL in the HTML changed, so the user's browser made a new request for the file. When the request reached Nginx, it got rewritten to the simple name of the file.
I would suggest using caching by ETags in this situation, see http://en.wikipedia.org/wiki/HTTP_ETag. You can then use the hash as the etag. A request will still be submitted for each resource, but the browser will only download items that have changed since last download.
Read up on your web server / platform docs on how to use etags properly, most decent platforms have built-in support.
Most modern browsers check the if-modified-since header whenever a cacheable resource is in a HTTP request. However, not all browsers support the if-modified-since header.
There are three ways to "force" the browser to load a cached resource.
Option 1 Create a query string with a version#. src="script.js?ver=21". The downside is many proxy servers wont cache a resource with query strings. It also requires site-wide updating for changes.
Option 2 Create a naming system for your files src="script083010.js". However the downside to option 1 is that this as well requires site-wide updates whenever a file changes.
Option 3 Perhaps the most elegant solution, simply set up the caching headers: last-modified and expires in your server. The main downside to this is users may have to recache resources because they expired yet never changed. Additionally, the last-modified header does not work well when content is being served from multiple servers.
Here a few resources to check out: Yahoo Google AskApache.com
This is really only an issue if your web server sets a far-future "Expires" header (setting something like ExpiresDefault "access plus 10 years" in your Apache config). Otherwise, a browser will make a conditional GET, based on the modified time and/or the Etag. You can verify what is happening on your site by using a web proxy or an extension like Firebug (on the Net panel). Your question doesn't mention how your web server is configured, and what headers it is sending with static files.
If you're not setting a far-future Expires header, there's nothing special you need to do. Your web server will usually handle conditional GETs for static files based on last modified time just fine. If you are setting a far-future Expires header then yes, you need to add some sort of version to the file name like your question and the other answers have mentioned already.
I have also been thinking about this for a site I support where it would be a big job to change all references. I have two ideas:
1.
Set distant cache expiry headers and apply the changes you suggest for the most commonly downloaded files. For other files set the headers so they expire after a very short time - eg. 10 minutes. Then if you have a 10 minute downtime when updating the application, caches will be refreshed by the time users go to the site. General site navigation should be improved as the files will only need downloading every 10 minutes not every click.
2.
Each time a new version of the application is deployed to a different context that contains the version number. eg. www.site.com/app_2_6_0/ I'm not really sure about this as users bookmarks would be broken on each update.
I believe that a combination of solutions works best:
Setting cache expiry dates for each type of resource (image, page, etc) appropreatly for that resource, for example:
Your static "About", "Contact" etc pages probably arn't going to change more than a few time a year, so you could easily put a cache time of a month on these pages.
Images used in these pages could have eternal cache times, as you are more likey to replace an image then to change one.
Avatar images might have an expiry time of a day.
Some resources need modified dates in their names. For example avatars, generated images, and the like.
Some things should never be caches, new pages, user content etc. In these cases you should cache on the server, but never on the client side.
In the end you need to carfully consider each type of resource to determine what cache time to instruct the browser to use, and always be conservitive if you are unsure. You can increase the time later, but it's much more pain to uncache something.
You might want to check out the approach taken by the grails "uiperformance" plugin, which you can find here. It does a lot of the things you mention, but automates them (set expiry time to a long time, then increments version numbers when files change).
So if you're using grails, you get this stuff for free. If you are not - maybe you can borrow the techniques employed.
Also - borrowed form the ui-performance page, - read the following 14 rules.
ETags seemingly provide a solution for this...
As per http://httpd.apache.org/docs/2.0/mod/core.html#fileetag, we can set the browser to generate ETags on file-size (instead of time/inode/etc). This generation should be constant across multiple server deployments.
Just enable it in (/etc/apache2/apache2.conf)
FileETag Size
& you should be good!
That way, you can simply reference your images as <img src='/path/to/foo.png' /> and still use all the goodness of HTTP caching.