> Your comment surprised me
The forum loads extremely fast for me, otherwise the 300 posts/page workaround would be prohibitive.
so, the files are being cached - and they are being served from cache but only AFTER an http request is made. using the htaccess solution i suggest, which sets a far-in-the-future expiration date, would allow the files to be served from the browser's cache without an http request/response to/from the server.
adding gzip compression would shrink text files by about 70%.
waterfall of how the page loads (including upon repeat view)
when properly configured the http response will look something like this:
HTTP/1.1 200 OK
Date: Sat, 28 May 2011 02:20:10 GMT
Last-Modified: Thu, 19 May 2011 08:41:17 GMT
Expires: Fri, 26 Oct 2012 08:46:50 GMT
Keep-Alive: timeout=15, max=298
[28/May/2011:10:15:35 +0100] "GET /cgi-bin/rybkaforum/forum_show.pl HTTP/1.1" 200 18758 "http://rybkaforum.net/cgi-bin/rybkaforum/forum_show.pl" "Mozilla/5.0 (Windows NT 5.2; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1" [28/May/2011:10:15:13 +0100] "GET /cgi-bin/rybkaforum/forum_show.pl HTTP/1.1" 200 18758 "http://rybkaforum.net/cgi-bin/rybkaforum/forum_show.pl" "Mozilla/5.0 (Windows NT 5.1) AppleWebKit/534.30 (KHTML, like Gecko) Chrome/12.0.742.60 Safari/534.30" [28/May/2011:10:25:37 +0100] "GET /cgi-bin/rybkaforum/forum_show.pl HTTP/1.1" 200 12926 "http://rybkaforum.net/cgi-bin/rybkaforum/forum_show.pl" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.2; WOW64; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)" [28/May/2011:10:30:57 +0100] "GET /cgi-bin/rybkaforum/forum_show.pl HTTP/1.1" 200 12924 "http://rybkaforum.net/cgi-bin/rybkaforum/forum_show.pl" "Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US) AppleWebKit/533.21.1 (KHTML, like Gecko) Version/5.0.5 Safari/533.21.1"
Yslow (statistics tab), for example, says only 12kb of primed cache is being used on repeat views of the homepage and the number of http requests is the same on repeat views as for first time views. Page Speed gives rybkaforum.net a score of 25/100. Rybkachess.com by comparison scores 70/100. My typical client pages score 90/100.
Am not sure why the logs don't show the 304 requests, but I am sure the caching could be improved and that this will make the forum feel faster, snappier and more responsive when corrected.
> Am not sure why the logs don't show the 304 requests
The logs do show 304 requests. There simply aren't any additional requests from the browsers I mentioned and in the end that's what matters. Everything but the .pl is loaded from cache. The only browser I saw making additional requests (resulting in 304) is Opera.
It's interesting how all these testing methods you refer to agree on "best practices", but the results don't agree with what I'm seeing in the logs.
As for Opera I have no idea why it decides to make these additional requests.
They both agree on the best way to cache a gif file. They also both agree about gzip and both use it on their own sites.
You say you aren't seeing 304's in the logs yet in your following sentence you say you are seeing 304's in the logs. Nice logic. Here's the shocking part, you favor your ignorant opinion over a consensus of expert opinion.
"As for Opera I have no idea why it decides to make these additional requests"
Because you're not setting an Expires header when you send the file.
Consider making these changes to save all of us 10-15 seconds per day.
> save all of us 10-15 seconds per day
All you Opera users?
> You say you aren't seeing 304's in the logs yet in your following sentence you say you are seeing 304's in the logs.
The only place where I mentioned not seeing 304 was in the following sentence.
> There simply aren't any additional requests from the browsers I mentioned and in the end that's what matters.
Note the highlighted part, where I refer to the browsers in my previous post (where I showed the logs for repeated requests of four browsers).
> Nice logic.
I think you need to explain your own "logic"
There are however quite a few browser installations that either don't cache at all, or not properly (constant 304s). The reasons here are manifold. Some people mess with their browser's caching configuration manually. Problematic addons also change the configuration, and/or the caching behavior directly. Proxies can completely change request behavior.
Some of the above comes from user experimentation, some from web editing tools, a few from corporate proxies, and I'm guessing most from the usual "Normantec" crapware, which always causes more problems than it solves. Using Refresh/F5 may also cause 304s for a while in some browsers.
Once a browser's standard caching behavior is changed, the output of addons like YSlow is meaningless in this regard. And regarding external test service providers - who knows what their configuration and behavior is. I've certainly see them behave rather differently than real browsers with default config.
In my experience, setting future expiration headers helps against a few of these non-cachers, but not the majority of them. Future expiration headers do of course cause new problems, unless you have a mechanism to force reloading in place, which is too complicated for most hobbyist webmasters (it's enabled here, though).
FWIW, there are also some freak issues caused by browsers, like e.g. Firefox 3.5- always loading background SVGs (which it can't use) without any caching whatsoever, but that should be limited to rather specific circumstances.
of course I use "IE"
> of course I use "IE"
Initial page load, second page load, gzip
chrome 37 requests, 2 requests, no
ie7 37, 37, no
ie8 37, 37, no
ie9 37, 2, no
here is another testing resource:
zoomph says the caching is set up incorrectly. http://rybkaforum.net/cgi-bin/rybkaforum/forum_show.pl earns a performance score of 58/100.
Here's an article by Steve Saunders on the topic of Expires headers.
The elo improvement i've noticed, using opera with prefetching, is +197 elo. From 1633 to 1830.
Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill