Performance Research, Part 2: Browser Cache Usage – Exposed!

Blog
About

Site Search:

Performance Research, Part 2: Browser Cache Usage – Exposed!

January 4, 2007 at 12:24 pm by Tenni Theurer | In Development, Performance | 81 Comments

This is the second in a series of articles describing experiments conducted to learn more about optimizing web page performance. You may be wondering why you’re reading a performance article on the YUI Blog. It turns out that most of web page performance is affected by front-end engineering, that is, the user interface design and development.

In an earlier post, I described What the 80/20 Rule Tells Us about Reducing HTTP Requests. Since browsers spend 80% of the time fetching external components including scripts, stylesheets and images, reducing the number of HTTP requests has the biggest impact on reducing response time. But shouldn’t everything be saved in the browser’s cache anyway?

Why does cache matter?

It’s important to differentiate between end user experiences for an empty versus a full cache page view. An “empty cache” means the browser bypasses the disk cache and has to request all the components to load the page. A “full cache” means all (or at least most) of the components are found in the disk cache and the corresponding HTTP requests are avoided.

The main reason for an empty cache page view is because the user is visiting the page for the first time and the browser has to download all the components to load the page. Other reasons include:

The user visited the page previously but cleared the browser cache.
The browser cache was automatically cleared, based on the browser’s settings.
The user reloaded the page in a way that caused the cache to be bypassed. For example, the browser will bypass the cache if you hold down the control-shift key while clicking the Refresh button in Internet Explorer.

Strategies such as combining scripts, stylesheets, or images reduce the number of HTTP requests for both an empty and a full cache page view. Configuring components to have an Expires header with a date in the future reduces the number of HTTP requests for only the full cache page view.

Previously, we observed where the time is spent when a user requests http://www.yahoo.com with an empty cache. When a user loads the page, the browser downloads approximately 30 components (see Figure 1). Figure 2 is a graphical view of where the time is spent loading http://www.yahoo.com with a full cache. Each bar represents a specific component requested by the browser. Since components are already in the cache on a full cache page view, and the Expires header has a date in the future, the browser only has to download three components including the HTML document

Figure 1. Loading http://www.yahoo.com with an empty cache

Figure 2. Loading http://www.yahoo.com with a full cache

Table 1 shows a summary of the total size and number of requests for each type of component to load http://www.yahoo.com. How much does a full cache benefit the user? Loading the page over my cable modem at home, it took 2.4 seconds with an empty cache and only 0.9 seconds with a full cache. The full cache page view had 90% fewer HTTP requests and 83% fewer bytes to download than the empty cache page view.

Table 1. Empty and Full Cache Summary to load http://www.yahoo.com

* Times were measured over cable modem (~2.5 mbps).

How many users view Yahoo! pages with a full cache?

The performance team at Yahoo! ran an experiment to determine the percentage of users and page views with an empty cache on some of Yahoo!’s most popular pages. We defined the experiment to measure users’ cache behavior related to a new component (an image). For this new image we measured the following statistics each day:

What percentage of users requested the new image?
What percentage of page views requested the new image?

The new image was configured with the following HTTP headers:

Expires: Thu, 15 Apr 2004 20:00:00 GMT
Last-Modified: Wed, 28 Sep 2006 23:49:57 GMT

When the browser saves a component in its cache, it also saves the Expires and Last Modified values. Specifying an Expires date in the past forces the browser to request the image every time the page is viewed (with a few exceptions, such as when users click the browser’s “back” button to return to a page). If the image is already in the browser’s cache and is being re-requested, the browser will pass the Last-Modified date in the request header. This is called a conditional GET request and if the image has not been modified, the server will return a 304 Not Modified response. The requests from browsers, therefore, result in one of the following response status codes:

200 — The browser does not have the image in its cache.
304 — The browser has the image in its cache, but needs to verify the last modified date.

Since the status codes are recorded in the apache access logs, we are able to determine the empty and full cache measurements by analyzing the logs.

The percentage of users with an empty cache is:

       # of unique users with at least one 200 response
                                                        
                    total # of unique users

The percentage of page views with an empty cache is:

                      # of 200 responses
                                                   
           # of 200 responses + # of 304 responses

Figure 3 shows the percentage of users and page views with an empty cache plotted over each day of the experiment. On the first day of the experiment, no one had these images cached so the empty cache percentage was 100%. As the days passed more users had the images cached, so the percentages dropped until at some point it reached a constant steady state.

Figure 3. Percentage of Users and Page Views with an Empty Cache

Suprising Results

40-60% of Yahoo!’s users have an empty cache experience and ~20% of all page views are done with an empty cache. To my knowledge, there’s no other research that shows this kind of information. And I don’t know about you, but these results came to us as a big surprise. It says that even if your assets are optimized for maximum caching, there are a significant number of users that will always have an empty cache. This goes back to the earlier point that reducing the number of HTTP requests has the biggest impact on reducing response time. The percentage of users with an empty cache for different web pages may vary, especially for pages with a high number of active (daily) users. However, we found in our study that regardless of usage patterns, the percentage of page views with an empty cache is always ~20%.

Conclusion: Keep in mind the empty cache user experience. It might be more prevalent than you think!

Share and extend: Bookmark with Yahoo! My Web | Bookmark with del.icio.us | digg it! | reddit!

81 Comments »

RSS feed for comments on this post. TrackBack URI

Do you have numbers representing how the same status codes break down by User-Agent? e.g. are people using IE more likely to have an empty cache than Firefox?

Were the logs cleaned first to remove non-browser access (i.e. crawlers, etc)?

Comment by Evan — January 4, 2007 #
When you say users does that mean “users logged in to Yahoo!”? Does the experiment do any filtering of traffic to exclude bots,scrapers,etc?

Comment by Joe Preston — January 4, 2007 #
I believe this result may be a side-effect of the cache size and replacement algorithms of the browsers. (My Firefox cache size is listed as 200MB, and IE7 shows 1GB, but no mention is made of an upper limit on number of individual files.)

I’ve observed this on my own applications. Where I have thumbnails set to expire a month in the future, quite often the browser will re-fetch the images if I don’t visit the page for a couple of days. The large number of tiny images and scripts my browser has seen in the meantime have pushed my cacheable images out of its cache.

Comment by Martin Kenny — January 4, 2007 #
@Evan, @Joe: The experiment contained a filter for removing traffic from robots, crawlers and internal ips. To further strengthen the validity of the data, we even applied additional filters such as removing users generating more than 40 page views per day (since generating that many page views in a single day was highly unlikely for a real user).

Comment by Tenni Theurer — January 4, 2007 #
Has there been any research on the total time taken for the 304 handshakes, especialy given that DSL lines are much slower in the request direction, and that the request can be quite large (500-700) bytes.

Comment by Tim Hawkins — January 5, 2007 #
Tha’s logical:

The cache is a danger for privacity (try Picasa!) and spend many sectors in HD (1 byte file = 32 kb in many modern HD)
Then many people (with ADSL conections) goes to:

IE: Tools/Internet Options/Advanced Options and X the last one: Empty temp folder…

Firefox: Tools/Options/Privacity/Clean always…

Comment by Yano — January 5, 2007 #
Great article. What tool(s) did you use to filter the logs?

Comment by Scott Hovey — January 5, 2007 #
[...] A month ago, I linked to the first article in a ‘Performance Research’ series by the YUI folks in which they explored how the number of HTTP requests impacts application performance. The second part of the series looks at caching. [...]

Pingback by Ajax Performance » Real world caching numbers from the YUI blog — January 5, 2007 #
@Tenni: Do you have any way of knowing that the “users” generating more than 40 page views a day were not just a group of users behind a corporate proxy server?

Comment by Joe Pearson — January 5, 2007 #
[...] Tenni Theurer has posted a second part of performance research on Browser Cache Usage – Exposed!. [...]

Pingback by Ajaxian » Browser Cache Usage: Only 40-60%? — January 5, 2007 #
What was used to create the graphs for figure 1? I looked for ages to find something like that and ended up writing a very crude version using curl. But it didn’t make nice graphs for me like that.

t

Comment by Toby — January 5, 2007 #
Tenni, very nice to see a very identical graph of your experiement. I did a little bit different test some months ago but came to a very similar result. On my test the page views percentage is higher because I think of less page count at all.

Comment by Michael Schwarz — January 5, 2007 #
Very interesting article. I find this really interesting information to see.

However, I this Martin Kenny could have an interesting point in his comment.

I’m going to use this information in a recommended im making. Thanks

Comment by Dougal Matthews — January 5, 2007 #
Performance Research, Part 2: Browser Cache Usage – Exposed!…

This is the second in a series of articles describing experiments conducted to learn more about optimizing web page performance. You may be wondering why you?re reading a performance article on the YUI Blog. It turns out that most of web page performan…

Trackback by Func. News — January 5, 2007 #
It would be very interesting to find a way to see what the reasons for the higher % of cache misses that were seen from the client’s side of things.

That might require some sort of quick survey to determine either cache settings or how people use their cache (as one other person mentioned, for security some people have it set to clean always)

Comment by Dan Smith — January 5, 2007 #
We use a transparent Squid proxy (http://www.squid-cache.org/) in our office as browsers don’t seem to do a good job of managing or using their own caches. It makes for a much more pleasant and zippy browsing experience! Unfortunately, it does not work with SSL requests, and I’ve found that some browsers (notably Safari) are particularly bad with using its cache for secure sites.

Comment by Patrick — January 5, 2007 #
I am new to doing fancy Javascript development, but I read recently that caching proxies will pretty much ruin your AJAX experience.

That makes sense, but what about caching in the browser? What are the downsides to browser caching?

Comment by Chris Blow — January 5, 2007 #
Squid is a pretty intelligent proxy server, and it does look at the various headers sent by the real web server. For an application that uses AJAX, it’s not going to cache the dynamic responses sent back from the server; what it does cache are images, style sheets, and script files which are the real culprits in slowing down an overall page request.

Comment by Patrick — January 5, 2007 #
I’m looking at the graphs here, but I don’t agree with your conclusions. I think what you’re really seeing is that 50% of your traffic is made up of frequently-returning users, while the other 50% are people who seldom visit — you know grandma who dials up once a month to check her email. The steep initial drop is representative of the frequent visitors, while the slow-sloped line is representative of the other group. Had you run your experiment longer, I think you would have found that the line for unique users would have continued a downward trend until it converged with the line representing page views without caching. This also IMHO better explains the giant gap between the views and unique visitors.

Comment by Dave Bialac — January 5, 2007 #
Just to supplement my previous comment and support my case a little more, note the 2 small bumps on the users curve that do NOT appear on the pages curve. These bumps fall exactly 7 days apart — a spike likely caused by more users viewing on that particular page.

Comment by Dave Bialac — January 5, 2007 #
@Chris: One downside to browser caching is that your users might not be using the latest version of a file. You can get around this by adding a version number to the filename at the cost of having to rev the filename and update all references to that file. Since most components are fairly static, caching them with a far future date helps save on HTTP requests (for full cache page views).

Comment by Tenni Theurer — January 5, 2007 #
The metrics will not clearly say anything about users with empty cache. Letz say I visit one of the pages where this tracking is done for the first time, my browser will do a empty cache request to the server. Then from the next time my browser will recieve a 304 (not modified) response. So the first 200 response should not be considered in the metric, therefore
The percentage of users with an empty cache is:

# of unique users with at least TWO 200 response / total # of unique users

Whatever metrics you guys have put up is invalid. It doesn’t depict anything about users who clears the cache everytime or browsers with settings that ignores cached files. Moreover the percentage of users with empty cache who are first time visitors to a website is 100%. The data that you guys have put up now is based on the total number of visitors to the website on that day of experiment. The user who has visited the website the first day is not required to visit the website on the second day. The graph depicts on how many new visitors are visiting the tracking pages every day. Not the users who ignore cached files.

Comment by prathap — January 6, 2007 #
Keep in mind that full page requests are done when a page is force-reloaded by the user as well, and all elements on the page will be requested again regardless of cache status of the reloaded elements.

I suspect that with a portal site such as Yahoo that forced page refreshes are a non-trivial number of requests.

Comment by Scott Anderson — January 7, 2007 #
[...] Performance Research, Part 2: Browser Cache Usage – Exposed! This is the second in a series of articles describing experiments conducted to learn more about optimizing web page performance. You may be wondering why you’re reading a performance article on the YUI Blog. It turns out that most of web page performanc (tags: performance user-experience webperf) No TagsLicenseThis work is published under a Creative Commons Attribution-NonCommercial-ShareAlike 2.5 License. « links for 2007-01-05 | [...]

Pingback by links for 2007-01-06 » dougmcclure.net — January 8, 2007 #
@Toby: Microsoft Excel has a feature under Chart Wizard > Custom Types > Floating Bars that can generate the graph like you see in Figure 1 and 2. For showing the components of an HTML page, I use IBM Page Detailer.

@Dave: I think you make an interesting point. We do run this experiment on different Yahoo! pages to determine correlations with usage patterns. Next time we’ll run it over a longer period of time and share our findings here.

@prathap: The purpose of the experiment was to find the percentages of users and page views visiting Yahoo! pages with an empty cache each day. Whatever reason why the image was not in the browser’s cache, the fact is the browser had to download the entire image again and that was what we were measuring. When the percentages dropped to a steady state, the returning users (with a full cache) reached a constant.

Comment by Tenni Theurer — January 8, 2007 #
[...] Tenni Theurer has posted a second part of performance research on Browser Cache Usage – Exposed!. [...]

Pingback by Browser Cache Usage: Only 40-60%? — January 9, 2007 #
[...] Performance Research, Part 2: Browser Cache Usage—Exposed! A fascinating look at the impact of client-side caches on the real-world performance on web sites. In particular, we see that Yahoo! sees 40-60% of its visitors arriving with no cached content, so the uncached load time of your site is very important. (tags: http) [...]

Pingback by SitePoint Blogs » News Wire: How’s Your Uncached Performance? — January 9, 2007 #
[...] Daha önce bu makalenin birinci kısmının linkini vermiştik. Web sitelerinde performansı arttırmanın yolarını üzerine Link [...]

Pingback by Fatih Hayrioğlu’nun not defteri » 12 Ocak 2007 Web’den seçme haberler — January 11, 2007 #
[...] I finally got around to reading the second article on browser performance optimisation on the YUI blog. While the techniques aren’t new to me (I work on the Yahoo! front pages for Europe remember), some of the data was. “40-60% of Yahoo!’s users have an empty cache experience and ~20% of all page views are done with an empty cache” [...]

Pingback by Kid666 Blog » Blog Archive » Browser-Cache-A-Go-Go — January 15, 2007 #
Let’s not forget, even a cache-lookup takes time.

If you could guarantee that most/all of your users had a full cache all the time, it would STILL be better and faster to concatenate static files wherever possible. Images should be sprite-ified, and CSS and JS should be minified.

In fact, according to my rough measurements, having a single script tag instead of several can significantly reduce the time required to parse and execute the code, even if we’re talking about inline scripts, where cache has no effect.

In short, caching is great and all, but don’t count on it to solve any problems. Build for the empty-cache situation, and you’ll usually benefit all of your users.

Comment by Isaac Z. Schlueter — January 16, 2007 #
40-60% users with an empty cache seems pretty high. I could understand that for Firefox users as they are considered more tech savvy to know how to delete private data. but I doubt that for the majority of IE users and normally they stand for the bigger piece of cake in the browser game…

Comment by 信用卡, 計算器 — January 17, 2007 #
[...] This week’s feature article on the 10 Rules to Code By generated a lot of comments (as well as 800+ guest visitors and 30+ new subscribers). One of the hottest discussions was about my claim that “there is never a valid need to add inline styling” to your markup. In the course of that debate a guest reader (named Matt) offered up some links from the internal Yahoo team about their performance research: The 80/20 rule and the truth about browser cache usage. [...]

Pingback by Browser and Page Performance » Professional Web Software Development — January 25, 2007 #
[...] “A single large file is fastest.” (Nate Koechley) That’s why Yahoo! apparently has such an amount of inline CSS. They found out browser caching is not as effective as they thought, in particular not on a user’s start page. So they deliver “inline” CSS. Actually writing inline CSS is a maintenance nightmare, but delivering CSS content inline doesn’t mean the files can’t have separate lives on the server: concatenate the files with a server side technique of your choice. [...]

Pingback by Learning the World » Website Performance Tweaks — January 25, 2007 #
CSS- und WebSite-Performance mit CSS-Sprites und Sliding-Doors…

Heute mal zum Thema, wie bekomme ich müde bzw. langsame Webseiten munter.Zuerst der schöne Artikel »Website Performance Tweaks« (s. 3. und 4.):learningtheworld.eu/2007/performance/CSS-Sprites: was ist das, was bringt das, wie geht das:yuiblog.com/bl…

Trackback by 11com7 Knowledge-Blog — January 26, 2007 #
[...] Of course with Yahoo’s performance research about browser cache and HTTP requests you could discuss if external files load faster with several server requests through script src="foo.js" or just one request and internal HTML code, but either way you should use central, non-redundant files and include them in one way or another. [...]

Pingback by Learning the World » Best Practices in Web Development — January 26, 2007 #
Really cool study. I second Evan request to see the differences of cache behaviour between browsers.

Comment by Monkeyget — January 27, 2007 #
[...] Our approach in the past has been to just cache everything and forget about it. Unlike many public websites that have to operate under the assumption that the user’s cache will be empty, we can depend on a fairly high percentage of populated caches. And, because we have a single page application design, even if they don’t have the JavaScript cached, they only have to download the files once and they’ll be available the entire time the application is being used. [...]

Pingback by Spider Bytes » Blog Archive » Smart JavaScript Caching — February 9, 2007 #
[...] Wer mag kann inzwischen auch mal bei meinem Bruder, CSSImport, CSSBeauty, CSSGuy ,F-LOG-GE oder Alistapart vorbeigucken, für Zwecke der Seitenoptimierung empfehlen sich noch diese, diese und diese Seite – seeehr interessant. ersteres bei Interesse an Bergen, schönen Bildern und Tourberichten, letztere für CSS/Webwork-Interessierte. Und weil es immer iweder Spass macht: Beetlebum. [...]

Pingback by Mal was anderes… - Cywhale.de:CoreBlog — February 12, 2007 #
[...] The last one is the topic I had in mind with the this blog’s title. Since Yahoo will be using the same locations for the libraries you need and since Yahoo is the most popular site, chances are your visitors have already checked their Y! mail or their Y! finance page and searched or done anything on the Yahoo network of sites. This means they have already requested and (hopefully) cached these .js files. And as proved before, lowering the number of HTTP requests is top 1 performance optimization you can ever do. [...]

Pingback by phpied.com » Blog Archive » YUI good for your performance — April 2, 2007 #
High Performance Web Sites: Rule 1 – Make Fewer HTTP Requests…

[Steve Souders is Yahoo!’s Chief Performance Yahoo!. This is one in a series of blogs describing the best practices he’s developed at Yahoo! for improving performance. This article is based on Chapter 3, Rule 1: Make Fewer HTTP Requests from……

Trackback by Yahoo! Developer Network blog — April 4, 2007 #
[...] Not everyone has cache turned on and many people who do have it turned on don’t let files fester in there forever, so there’s no guarantee the files you dump onto the user’s hard drive will actually be there the next time they visit. Yahoo published some numbers on this subject in January: “40-60% of Yahoo!’s users have an empty cache experience and ~20% of all page views are done with an empty cache.” [...]

Pingback by No Mod Required » Blog Archive » Don’t plan around a users second visit or page view… — April 10, 2007 #
We can use apache deflate_module to compress the content before sending it to the client.

http://httpd.apache.org/docs/2.0/mod/mod_deflate.html

Comment by Anand Muthu — April 11, 2007 #
14 rules for fast web pages…

Steve Souders of Yahoo’s “Exceptional Performance Team” gave an insanely great presentation at Web 2.0 about optimizing website performance by focusing on front end issues. Unfortunately I didn’t get to see it in person but the Web 2.0 talks……

Trackback by Skrentablog — May 9, 2007 #
[...] http://yuiblog.com/blog/2007/01/04/performance-research-part-2/ [...]

Pingback by » How to Build Insanely Fast Web Pages · Tech Blog · Techasaur.us Rex - Tech News Encyclopedia | Yesterday, Today & Tomorrow’s Tech News — May 12, 2007 #
[...] Performance Research, Part 2: Browser Cache Usage – Exposed! [...]

Pingback by Top methods for faster, speedier web sites — May 23, 2007 #
[...] http://yuiblog.com/blog/2007/01/04/performance-research-part-2/ Tags: performance, optimization, cache, browser, http, web, programming, caching(del.icio.us history) [...]

Pingback by Performance Research, Part 2: Browser Cache Usage - Exposed! » Yahoo! User Interface Blog — June 10, 2007 #
[...] for improving performance for first time visitors. As described in Tenni Theurer’s blog Browser Cache Usage – Exposed!, 40-60% of daily visitors to your site come in with an empty cache. Making your page fast for these [...]

Pingback by Yahoo! представи YSlow - Netlabs Bulgaria Blog — July 26, 2007 #
[...] for improving performance for first time visitors. As described in Tenni Theurer’s blog Browser Cache Usage – Exposed!, 40-60% of daily visitors to your site come in with an empty cache. Making your page fast for these [...]

Pingback by Thirteen Simple Rules for Speeding Up Your Web Site at think room — July 26, 2007 #
[...] Performance Research, Part 2: Browser Cache Usage - Exposed! Performance Research, Part 2: Browser Cache Usage – Exposed! [...]

Pingback by Performance Research, Part 2: Browser Cache Usage - Exposed! « ilab — July 29, 2007 #
[...] with including version numbers in the file names) saves basic HTTP calls for component data in about 3/4 of all page visits. Bad Penguin explains how to cache from the code [...]

Pingback by BlogSchmog » TuningSchmuning — August 5, 2007 #
[...] Browser Cache Usage – Exposed! [...]

Pingback by Client side web site performance — onenaught.com — August 6, 2007 #
nice post.. btw: did you tried YSlow against the blog site ? eheh – Performance Grade: D (68)

Comment by Felipe Gaucho — August 8, 2007 #
[...] an empty cache experience and about 20% of all page views are done with an empty cache (see this article for more information on browser cache usage) This fact outlines the importance of keeping web pages [...]

Pingback by Julien Lecomte’s Blog » Introducing the YUI Compressor — August 13, 2007 #
[...] for improving performance for first time visitors. As described in Tenni Theurer’s blog Browser Cache Usage – Exposed!, 40-60% of daily visitors to your site come in with an empty cache. Making your page fast for these [...]

Pingback by Howto: Create Faster Web Sites (13 rules to speed up website) « ****Linux rules the heart of its users. This is enough a reason why one should embrace Linux******* — August 15, 2007 #
[...] Glaubt man den Ingenieuren von Yahoo, haben 40% bis 60% der Yahoo Benutzer Erfahrungen mit leerem Cache und 20% aller Seitenaufrufe erfolgen gar ohne Cache (mehr zu diesem Thema in diesem Blogeintrag). [...]

Pingback by Wieso JavaScript komprimieren? | IT.CappuccinoNet.com Blog — August 16, 2007 #
40-60% users with an empty cache seems pretty high. I could understand that for Firefox users as they are considered more tech savvy to know how to delete private data. but I doubt that for the majority of IE users and normally they stand for the bigger piece of cake in the browser game…

Comment by online marketing china — August 17, 2007 #
[...] Performance Research, Part 2: Browser Cache Usage – Exposed! » Yahoo! User Interface Blog [...]

Pingback by Diigo Diary 08/17/2007 « Benx Blog — August 17, 2007 #
The best possible way to achieve cacheability of an object is to perform a server-side re-write of all linked content (images, scripts etc) and re-write the links to refer to a file name based off the MD5 hash of the file content.

So, your link:

http://us.i1.yimg.com/us.yimg.com/i/ww/beta/y3.gif

is re-written:

http://us.i1.yimg.com/never-expire/A31D5F12.gif

Where A31D5F12 is the MD5 hash.

The never-expire directory is configured via the Apache .htaccess file (with mod_expires) so that all content contained expires a long time in the future.

Since the hash generates a globally unique value from a given file (ahem), the content is cacheable forever. Any referenced media can be treated in this way.

Every time any linked media is changed, the page must be re-written and the appropriate new MD5 based file names substituted.

Comment by Chris Wooldridge — September 5, 2007 #
The cacheability checker will help anyone

http://www.mnot.net/cacheability/

Also, see

http://www.web-caching.com/

Comment by Chris Wooldridge — September 5, 2007 #
[...] into the service with an empty browser cache (a figure derived as the result of a great deal of research on the topic by Yahoo), one can derive the following [...]

Pingback by Graphics Optimization » Blog Archive » Meebo Me! (.png) — November 7, 2007 #
[...] mais sobre cache [...]

Pingback by Meio Código » Blog Archive » Melhorando o tempo de carregamento de um site — December 20, 2007 #
I’ve overheard quite a few times that using 304 as a response to Yahoo/Google crawlers may affect the way my website is ranked afterwards.

Is there any piece of truth behind that affirmation?

Comment by Fernando Beck — December 22, 2007 #
[...] 20 percent of all views of that page are occurring with an empty browser cache, according to studies conducted at Yahoo (the logo image not being in a visitor’s browser cache, either because the have not visited [...]

Pingback by Graphics Optimization » Blog Archive » Google.com Search Engine (.gif/.png) — January 29, 2008 #
[...] some might argue that testing the speed of un-cached pages would be unfair, however according to Yahoo’s research on caching, approximately 50% of users will never have the opportunity to have the page contents be cached. [...]

Pingback by John Resig - JavaScript Library Loading Speed — February 5, 2008 #
[...] describing experiments conducted to learn more about optimizing web page performance (Part 1, Part 2, Part 3, Part 4). You may be wondering why you’re reading a performance article on the YUI [...]

Pingback by Performance Research, Part 5: iPhone Cacheability - Making it Stick » Yahoo! User Interface Blog — February 6, 2008 #
[...] de un sistema operativo, éstas otras han de ser descargadas (si no han sido cacheadas, lo que sucede el 50% de las veces) por cada usuario que visualice la web. Esto supone un problema de rendimiento, ya que [...]

Pingback by Comprimir el código Javascript — February 8, 2008 #
[...] которые заходят к вам в первый раз. Как сказано в блоге Tenni Theurer’а: «40-60% посетителей приходят на сайт с пустым кешем». [...]

Pingback by Способы ускорения загрузки Вашего сайта | Записки маленького юниксоида — February 10, 2008 #
[...] 80% of those page views are done with a primed cache (based on Yahoo!’s browser cache statistics). We’re down to 80M page [...]

Pingback by High Performance Web Sites :: How green is your web page? — March 6, 2008 #
[...] 80% of those page views are done with a primed cache (based on Yahoo!’s browser cache statistics). We’re down to 80M page [...]

Pingback by Wie ‘grün’ ist Ihre Webseite? | IT.CappuccinoNet.com Blog — March 11, 2008 #
Have you done any similar research to sites using https/ssl? It seems that the browsers cache usage is very different once the content is delivered with ssl in some cases never appearing to cache any content, even small images – though using css does seem to help.

Comment by Kevin Pearcey — March 18, 2008 #
[...] 很多网站的 UI 设计人员为了达到某些视觉效果，会在一些用户需要频繁访问的页面模块上应用大量的图片。这样的情况，研究表明，对于用户粘度比较高的站点，在Web 服务器上对这一类对象设置 Expires Header 就是十分有必要的，大量带宽就这么节省下来，费用也节省了下来。顺便说一下，对于验证码这样的东西，要加个简单的规则过滤掉。 [...]

Pingback by 挖芋头 » Blog Archive » 闲谈 Web 图片服务器 — March 22, 2008 #
[...] for improving performance for first time visitors. As described in Tenni Theurer’s blog Browser Cache Usage – Exposed!, 40-60% of daily visitors to your site come in with an empty cache. Making your page fast for these [...]

Pingback by Best Practices for Speeding Up Your Web Site « Latest PHP - Mysql Technical News — March 27, 2008 #
[...] for improving performance for first time visitors. As described in Tenni Theurer’s blog post Browser Cache Usage – Exposed!, 40-60% of daily visitors to your site come in with an empty cache. Making your page fast for these [...]

Pingback by To Speeding up Your Web Site « Sanantoniowebdesign Weblog — August 3, 2008 #
Hi,

I’ve a lot of confusion about Header Expires. I know it enables the users to load the pages fast if the components like CSS, images, scripts etc… in cache. But the thing I want to know is What is the syntax to use this, and where to use? I mean where to use this Header Expires in the html file or in CSS file?

Your help is valuable to me and greatly appriciated.

Regards,

SreeRam.

Comment by SreeRam — August 19, 2008 #
@SreeRam: The Expires header can be set in your web server configuration. For example, Apache uses optional modules to include headers, including both Expires and Cache-Control. Use the ExpiresDefault directive to set an expiration date relative to the current date. For more information on this rule, take a look here.

Comment by Tenni Theurer — August 19, 2008 #
I am managing a website that has hundreds of thousands of new unique visitors daily. Which means that they have empty cache, how to cope up with this problem in a high javascript/css/AJAX based website?

Comment by PHP >> MySQL >> Performance >> security — November 1, 2008 #
for the best result, how long must we set expires header?

Comment by Anton Ongsono — December 25, 2008 #
IE’s cache has been broken since the start, it will not check for new copies of a page at appropriate times, IE does not work with dynamic websites unless you effectively disable the cache. That is part of the reason you will always see 20% or more no cache page views.

Comment by auser — March 29, 2009 #
Is it possible to specifying conditional caching within for page loads? i.e. cache the html but do not cache the javascript that it links to, for example?

Comment by File Rename Guy — April 15, 2009 #
for HTTP STATUS 304, we still need time to check if the media modified or not, right? how to remove the checking time?

Comment by callrid — April 16, 2009 #
[...] Performance Research, Part 2: Browser Cache Usage – Exposed! [...]

Pingback by Page load speed and website optimization. Google and Yahoo optimization tips — June 14, 2009 #

Yahoo! User Interface Blog