{"id":1632,"date":"2013-08-12T22:16:02","date_gmt":"2013-08-12T22:16:02","guid":{"rendered":"http:\/\/www.sitekickr.com\/blog\/?p=1632"},"modified":"2013-08-12T22:16:02","modified_gmt":"2013-08-12T22:16:02","slug":"rename-assets-live","status":"publish","type":"post","link":"https:\/\/www.sitekickr.com\/blog\/rename-assets-live\/","title":{"rendered":"Rename your assets before going live"},"content":{"rendered":"<p>One of the most annoying issues I face as a web developer is browser caching. Often, after I perform a minor revision to a site&#39;s CSS or JavaScript, I get an email from a client wondering why they don&#39;t see the changes on the production version of the website.<\/p>\n<p>I used to say, &quot;Just refresh the page!&quot;, which causes the browser to pull new files from the server. This is also know as <em>invalidating<\/em> a cached object.<\/p>\n<p>But occasionally, I get a particularly savvy client who asks, &quot;well, won&#39;t all of the returning visitors have to do the same thing?&quot; In which case, I&#39;d explain the whole cache expiration date thing, and how after a certain amount of time, the browser will grab new assets from the server (according to the cache headers I&#39;ve setup for their site). This is usually okay, as long as your changes don&#39;t significantly affect the layout of the site.<\/p>\n<p>As time went on, I had realized that I needed to make it a matter practice to ensure that certain assets were invalidated when going live. But, how can this be done? If a browser already has an expiration date for an asset, it won&#39;t check that asset again until &quot;time&#39;s up&quot;. Hence, it will continue to load it from the cache. So, what we need to do is &quot;trick&quot; the browser into thinking it&#39;s a completely new asset.<\/p>\n<h3>Method #1 &#8211; Renaming the asset<\/h3>\n<p>I used this method for a while, until I realized it caused SEO issues with images, particularly, 404 Not Found responses.<\/p>\n<p>You might have guessed that this method involves simply renaming the asset on the file system and, correspondingly, in your code. The browser will then realize that it doesn&#39;t have file with this name inside it&#39;s cache, and will continue to download it from the server.<\/p>\n<p>As I stated above, this method has one very big pitfall, it breaks links.<\/p>\n<p>If you rename image.jpg to image1.jpg, any links to that image will have been broken. Some might consider this a good thing, as it certainly keeps other webmasters from using images on your server! But, consider the impact on Google Image Search (and other image search engines).<br \/>\n\t&nbsp;<\/p>\n<h3>Method #2 &#8211; Adding a query string parameter<\/h3>\n<p>The better approach, which still causes browser&#39;s to download a new version of the asset from the server, is to simply append or change a query string parameter on the image source attribute. For example:<\/p>\n<p><code>&lt;img src=&quot;http:\/\/www.mysite.com\/images\/myimage.jpg&quot; alt=&quot;&quot; \/&gt;<br \/>\n\t&lt;img src=&quot;http:\/\/www.mysite.com\/images\/myimage.jpg?v=1&quot; alt=&quot;&quot; \/&gt;<\/code><\/p>\n<p>By incrementing a single query string parameter with each revision to the asset, you keep the browser coming back to the server, instead of to it&#39;s cache to load the asset.<\/p>\n<p>&nbsp;<\/p>\n<p>In summary, it would seem that method #2 is the best approach. However, method #1 would still be appropriate for CSS and JavaScript assets, as we&#39;re generally not concerned with breaking external links to that type of file.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>The browser cache can really cause headaches when a site is updated. This post details the easiest possible way to invalidate an asset when making your web revisions live.<\/p>\n","protected":false},"author":1,"featured_media":1639,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"amp_status":""},"categories":[41],"tags":[229,114],"_links":{"self":[{"href":"https:\/\/www.sitekickr.com\/blog\/wp-json\/wp\/v2\/posts\/1632"}],"collection":[{"href":"https:\/\/www.sitekickr.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.sitekickr.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.sitekickr.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.sitekickr.com\/blog\/wp-json\/wp\/v2\/comments?post=1632"}],"version-history":[{"count":6,"href":"https:\/\/www.sitekickr.com\/blog\/wp-json\/wp\/v2\/posts\/1632\/revisions"}],"predecessor-version":[{"id":1640,"href":"https:\/\/www.sitekickr.com\/blog\/wp-json\/wp\/v2\/posts\/1632\/revisions\/1640"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.sitekickr.com\/blog\/wp-json\/wp\/v2\/media\/1639"}],"wp:attachment":[{"href":"https:\/\/www.sitekickr.com\/blog\/wp-json\/wp\/v2\/media?parent=1632"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.sitekickr.com\/blog\/wp-json\/wp\/v2\/categories?post=1632"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.sitekickr.com\/blog\/wp-json\/wp\/v2\/tags?post=1632"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}