We use it every day to monitor the performance of our websites. This is a great help to increase the quality and speed of our sites. Thanks to it we gain a lot of time.
So, why the response time is increasing ? It should be better but certainly not worse.
When we look carefully to the response time for web browser, we see that the effect of optimization is not the same for all.
On the one hand, we have IE and Chrome, that have better time after the optimization, on the other hand we have Firefox that is worse.
January 03, 2012
IE = 3.78s
Firefox = 5.31s
Chrome = 3.55s
January 04, 2012
IE = 3.33s (-12%)
Firefox = 17.18s (+223%)
Chrome = 2.99s (-16%)
Now let’s look more closely at the statistics for Firefox. January 03, 2012
Firefox 7.0.1 : 2.54s
Firefox 8.0.0 : 6.00s
Firefox 8.0.1 : 5.87s
Firefox 9.0.1 : 4.04s
January 04, 2012
Firefox 7.0.1 : 21.73s (+755%)
Firefox 8.0.0 : 21.53s (+258%)
Firefox 8.0.1 : 18.69s (+218%)
Firefox 9.0.1 : 2.89s (-28%)
So what’s the problem with Firefox 7 & 8 ?
A little bit of searching on google gave me a answer: the problem is due to a bug on the Navigation Time API on firefox 7 & 8.
So to summarize, optimization, consisting of some scripts to load after the onload of the page, lowers the loading time, triggering event “onload” earlier.
This is true for all browsers.
But a bug in Firefox (<9) broke the statistics of loading time.
The problem is that google think our website has become slower even though it has become faster.
We will see in few days if the statistics are better.
Edit of January 13, 2012:
As you see, the workaround is good.
Comparison between Dec 31,2011 – Jan 3,2012 (before onload) and Jan 9,2012 – Jan 12,2012 (after onload):
Firefox 7 / 8 are still slower when scripts are loaded after onload. Fortunately, the number of visit of these browsers falls sharply in favor of Firefox 9.
A crasher bug when requests were queued and the backend sent a response with Vary has been fixed.
A crash when a too large synthetic response was produced has been fixed.
The ban lurker now properly sleeps the 1 second it is supposed to.
Varnish now releases disk space properly if no -s argument is provided, and the default cache size is now 100MB instead of 50% of the available disk space.
I’ve just migrated this blog on a dedicated server.
In order to use Varnish 3.0.1, i have done few ajustements on the wordpress.vcl contained in the wordpress plugin for Varnish