We want to set expires headers for used images, css and javascript to improve pagespeed, but we are aware of the cachingproblem when modifying a css or js script.
Is it possible to add a meta or other tag in the file which loads the xhtml which tells the browser to refresh every element, no matter what caching is set on existing images, css or js?
As far as I know, there's no such shortcut.
And even if it was - what would be the point? Sending such a header would defeat the purpose of the future expiration header in the first place.
When setting expiration headers, you need to add some sort of asset versioning to to your elements, such as <link rel="stylesheet" href="css/style.css?v=2">
Changing the path to the asset would achieve the same goal.
Yes this is a hassle. But cache invalidation is a hard problem, there's really no easy way around it.
What you probably want to do is version your static content. so say you have a main.css file then you can version this by renaming it to main_0.css (just an example) and then you would set the cache expire to a year. if you ever need to update main.css just increment the version number and update your references. Then all clients will get the latest version.
There are several solutions that can do this versioning for you, but this is the basic principle..
I have always found theese resources very usefull when having cache related questions:
http://code.google.com/intl/no/speed/page-speed/docs/caching.html
http://code.google.com/intl/no/speed/page-speed/docs/filters.html
Hope this helps.
EDIT
Here is a versioning solution (mod_pagespeed) that does what i explained above:
http://code.google.com/intl/no/speed/page-speed/docs/filter-cache-extend.html
Is it possible to add a meta or other tag in the file which loads the xhtml which tells the browser to refresh every element, no matter what caching is set on existing images, css or js?
Not as far as I'm aware.
We want to set expires headers for used images, css and javascript to improve pagespeed
This is a good thing in my opinion.
but we are aware of the cachingproblem when modifying a css or js script.
If you're making drastic changes to CSS or JS then you ought to be staging the changes anyway. Manage these changes by having the new CSS and JS on a different path and change the references in your HTML when making the change. This allows you to:
instantly roll out / back
make selective rollouts by dynamically generating those references
web logs now provide clear audit trail for following up bug reports
avoid any issues with short term caching of CSS and JS
Related
I have a website which specify's a background image from the CSS.
The client has asked us if it would be possible to have different backgrounds for each page (category technically). let call their site clients.com
Unfortunately we don't own the website, simply manage it for a client and as such have very limited access... We can update the CSS but not much in the way of HTML (or .aspx technically).
My idea was, we may be able to specify the background image source from somewhere else, perhaps another server at resources.clients.com Ideally the other server would return different images based on the URL which requested the data. Perhaps I'd have a database of URLs and the returned image file, with unspecified URLs loading a default...
Any thoughts on how this might be achieved, or other suggestions would be greatly appreciated. I am intrigued about how this could be done on a personal level, not just for this project/clients sake.
Thanks :D
I'm afraid your idea won't work. There are several reasons for that. The request for resources mentioned within a style sheet file is made by the page visitor's browser. This browser won't send any information on which page was visited.
You'd be better off asking the developers of the application to add category specific CSS classes to the body of the page. So you can define according styles.
Another reason why your approach won't work is browser caching. Referencing one image in a CSS file without any other information will make the browser cache this file (I suppose caching headers are not disabled on the application server). So when the visitor is heading for another category page, the browser will still serve the picture loaded for the previous category.
Ive made a minor text change to our website, the change is minor in that its a couple of words, but the meaning is quite significant.
I want all users (both new and returning) to the site to see the new text rather than any cached versions, is there a way i can force a user (new or returning) to re download the page, rather than fetch it from their browser cache ?
The site is a static html site hosted on a LAMP server.
This depends totally on how your webserver has caching set up but, in short, if it's already cached then you cannot force a download again until the cache expires. So you'll need to look at your cache headers in your browsers developer tools to see how long it's been set for.
Caching gives huge performance benefits and, in my opinion, really should be used. However that does mean you've a difficulty in forcing a refresh as you've discovered.
In case you're interested in how to handle this in the future, there are various cache busting methods, all of which basically involve changing the URL to fool the browser into thinking its a different resource and forcing the download.
For example you can add a version number to a resource so you ask for so instead of requesting index.html the browser asks for index2.html, but that could mean renaming the file and all references to it each time.
You can also set up rewrites in Apache using regular expressions so that index[0-9]*.html actually loads index.html so you don't need multiple copies of the file but can refer to it as index2.html or index3.html or even index5274.html and Apache will always serve the contents of index.html.
These methods, though a little complicated to maintain unless you have an automated build process, work very well for resources that users don't see. For example css style sheets or JavaScript.
Cache busting techniques work less well for HTML pages themselves for a number of reasons: 1) they create unfriendly urls, 2) they cannot be used for default files where the file name itself is not specified (e.g. the home page) and 3) without changing the source page, your browser can't pick up the new URLs. For this reason some sites turn off caching for the HTML pages, so they are always reloaded.
Personally I think not caching HTML pages is a lost opportunity. For example visitors often visit a site's home page, and then try a few pages, going back to the home page in between. If you have no caching then the pages will be reloaded each time despite the fact it's likely not to have changed in between. So I prefer to have a short expiry and just live with the fact I can't force a refresh during that time.
When editing a custom .css.liquid file that is not automatically set up by Shopify and cannot be placed in a page (since it does not have access to Shopify's Liquid templating system), I find that it can take hours for the CDNs to start serving up the new version of said .css.liquid file.
In the future, how can I cut down on this waiting time? Currently, here's what I think is going on:
Most asset urls have some number appended to them, like so: path/to/filename?270. It could be that this number is meant to represent last time file was served, version number, or some other flag to indicate to serve up the file. If so, then I can just create a template to grab this info myself (though I prefer not having to take an additional step.
The CDN servers' cache times are high, and will not reissue a new representation of the file until the data in the cache has expired. If so, there's not much I can do about this.
Please let me know if it's one of the above situations, or if it's something else.
I've had success with re-saving the layout file that calls the .css.liquid file.
For example: edit something then save it up to the server. And then edit it back again and save that back up to the server.
This seems to increment the query string on the path to the css file.
I've noticed that many pages with heavy javascript load certain files at the end so pages load faster, can sprockets help me do this in Rails 3? If not, what methods can I use to help performance when using scripts?
There are a few things to consider here - first, the browser. Most modern browsers can asynchronously load resources, so the old trick of putting javascript at the end of the html isn't as necessary as it once was. Have a read through this article on asynce at css-tricks: http://css-tricks.com/thinking-async/
Next, the point of the asset pipeline is to concatenate, minify and compress all the javascript and css into two files, one 'application.js' and one 'application.css'.
This serves to reduce HTTP requests and means that only the first page load will take
The logic is, that with proper caching, the first load will take longer to get the monster files, but once they've been downloaded, the user has the js and stylesheets cached on their machine.
Have a read through the asset pipeline guide for more information about its use and benefits: http://guides.rubyonrails.org/asset_pipeline.html
When mvc3 was created I placed one of these on my _layout.cshtml page...
#Html.RenderCss()
#Html.RenderScript()
Then in my inheriting razor pages I did this...
#Html.RegisterScript("~/Content/scripts/myscript.js")
Is there now an automatic way to do this with the optimisation dlls that. I dont really want to bundle everything in the folder all the time. Id also like it to minify the file too automatically. Not sure if im missing the point of this bundling feature but i just want to add files dynamically and then have them render out all at the same place on the page...
Thanks...
My understanding of the bundling feature, which is still pre-release and somewhat buggy is that it is designed to combine and then minify all of your CSS or JS files you might need in your project. It then uses a versioning mechanism so that clients get the full browser caching experience.
For example if I have 3 CSS files (Reset.css, Global.css, and Site.css) these all get downloaded on the first visit to my site, they are combined and minified so the file size is quite small. The url contains a special hash number/querystring. As long as I don't change the content the cached copy stays on the client until it expires or they clear their temp files. When I make a change the old version is discarded and a new hash is created. When the client visits again their file is now invalid and it redownloads the new file.
I personally have not tried to create specific bundles but with a search I found someone who has created a custom bundle, I think this may be along the lines of what you are trying to accomplish: http://www.codeproject.com/Tips/389545/ASP-NET-MVC4-Bundling-and-Minification