yslow website stats

Brennan Ashton bashton at brennanashton.com
Sat Jan 9 02:37:26 UTC 2010


On Fri, Jan 8, 2010 at 9:04 PM, Mike McGrath <mmcgrath at redhat.com> wrote:
> On Fri, 8 Jan 2010, Toshio Kuratomi wrote:
>
>> On Fri, Jan 08, 2010 at 10:42:35AM -0800, Darren VanBuren wrote:
>> > On the matter of Expires, here's what would need to be added to an
>> > Apache config, assuming static stuff is in /srv/web/static:
>> >
>> > <Directory /srv/web/static>
>> > ExpiresByType image/gif "access plus 1 month"
>> > ExpiresByType image/png "access plus 1 month"
>> > ExpiresByType text/css "access plus 1 month"
>> > ExpiresByType text/javascript "access plus 1 month"
>> > </Directory>
>> >
>> > Of course we can tweak the times, I just made up 1 month.
>> >
>> Is this how Expires work? ::
>>
>>   * Client requests fp.o/static/fedora.css
>>   * Client receives fedora.css with an Expires line of 1 month
>>   * For the next month, the client does not retrieve new versions of
>>     fedora.css.
>>
>> If so, we're either going to want to keep the Expires time pretty low (an
>> hour or less) or start adding version information into all of our static
>> resources.
>>
>
> That's a great question and one I've been curious about as well.  how's
> that whole system supposed to work?  What if I close the browser?  Will
> it still use the cache if it was set to 1 month?
>
>        -Mike

My understanding from the limited amount of cache stuff I have done is
that if you use Expires and have it set for a month, then the data
will sit on the browser's computer for that time, or until the cache
is manually cleared. However thanks to HTTP 1.1 we now have access to
cache-control headers [1] which includes "must-revalidate" and
"proxy-revalidate" which creates a check to see if the data is the
most recent or if it needs to be resent, this is more traffic, but can
increase confidence that it is the newest data.

This:
Cache-Control: max-age=3600, must-revalidate

would require a check, and also expire every 3600 seconds.


[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9

--Brennan Ashton




More information about the infrastructure mailing list