Topic Forum Assistance & Feedback / Questions or Suggestions Related to the Forum / Speed up the forum
![[cz]](/mwf/v12/flags/cz.png "Czech Republic")
Please consider adding caching rules to your htaccess file so javascript and css files get cached.
![[is]](/mwf/v12/flags/is.png "Iceland")
Looking into this.
Your comment surprised me because the forum is already configured for caching. I have now tested Chrome, FireFox and Opera and all of them use a cached copy of images (PNG, JPG, GIF...), CSS and JavaScript files so the caching scheme seems to be working fine. An example is shown below. Is your browser loading the files from the server on every request?
![[mx]](/mwf/v12/flags/mx.png "Mexico")
> Your comment surprised me
+1
The forum loads extremely fast for me, otherwise the 300 posts/page workaround would be prohibitive.
on repeat visits/page views the problem is the browser making http requests to the server for files which are cached. the request includes an If-Modified-Since date, the server sends a 304 response and an Etag - the browser then uses it's cached version of the file.
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)
http://www.webpagetest.org/result/110528_WN_PZXK/
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
Server: Apache
Last-Modified: Thu, 19 May 2011 08:41:17 GMT
Accept-Ranges: bytes
Cache-Control: max-age=44692000
Expires: Fri, 26 Oct 2012 08:46:50 GMT
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 6057
Keep-Alive: timeout=15, max=298
Connection: Keep-Alive
Content-Type: text/css
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)
http://www.webpagetest.org/result/110528_WN_PZXK/
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
Server: Apache
Last-Modified: Thu, 19 May 2011 08:41:17 GMT
Accept-Ranges: bytes
Cache-Control: max-age=44692000
Expires: Fri, 26 Oct 2012 08:46:50 GMT
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 6057
Keep-Alive: timeout=15, max=298
Connection: Keep-Alive
Content-Type: text/css
Here is what the access log shows me for the four most popular browsers on the forum (Firefox, Chrome, IE and Safari) on repeat visits. They only send a single request (for the .pl page itself) and no extra requests for the cached resources. In other words this looks as efficient as can be.
[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"
Webpagetest.org, pagespeed (firefox addon), yslow (firefox addon) and redbot.org all agree that the files aren't being cached in accordance with best practices.
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.
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.
Page Speed is developed by Google. YSlow is developed by Yahoo.
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.
Thanks.
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.
Thanks.
> 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"
For vanilla browser installations, there's no need to fake any expiration headers, they will automatically cache files and not make constant if-modified-since/304 requests (exception: for files with recent timestamps). There will of course be some variation between vendors and versions, but this is at least true for the common desktop browsers, incl. Opera.
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.
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.
![[us]](/mwf/v12/flags/us.png "United States")
FWIW I think the speed is fine as is!
of course I use "IE"
I think the speed is fine as is! of course I use "IE"
> of course I use "IE"
GZIP compression, a topic all of you have failed to mention - is not being used. All browsers agree.
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:
http://zoompf.com/free
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.
http://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/
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:
http://zoompf.com/free
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.
http://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/
In fairness, using opera, I've noticed the forum loading faster since this thread was started. ;)
I've not had problem with loading or loading time before. Only a couple have I had issues with the speed of the forum.
I've never had problems with the forum's speed, always, when pages are taking too much to load, it has been because of my ISP. I can't actually imagine it being faster, that's why I found weird this thread, it's like those guys that want to have the engine 5 elo stronger even if they cannot tell the difference
+1
I certainly can tell the difference. Either a server setting was adjusted, or the changes I made to my system removed the latency.
The elo improvement i've noticed, using opera with prefetching, is +197 elo. From 1633 to 1830.
The elo improvement i've noticed, using opera with prefetching, is +197 elo. From 1633 to 1830.
Topic Forum Assistance & Feedback / Questions or Suggestions Related to the Forum / Speed up the forum
Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill