I am more interested in the cause of poor page loading speed on Chrome/Windows, since this combo covers the vast majority of our users.


The average page speed in the last month is 55 seconds for Chrome/Windows and 53 seconds for Safari/Linux (!).

Indeed, our website is not extremely well optimized concerning the general page speed (the homepage scores 77/100 in PageSpeed Insights from Google). Some of the issues :

  • It is not delivered via CDN
  • It has a pretty high server response (0.89)

We are working on solving these issues.

My possible answer for this problem, that needs a confirmation :

  • it has a huge .htaccess file, with ~1660 lines of redirects.

I learned from other resources that having a big .htaccess file can slow down a lot the page speed, but I still wonder why we only encounter this problem on Chrome/Windows and Safari/Linux.

Did anyone else stumble upon this issue before? Does Chrome has a special way of loading a website based on the .htaccess file's content?

  • 1
    .htaccess is entirely server-side and doesn't really have anything to do with the browser. So, if your site is loading OK in some browser/platforms then it's unlikely to be a .htaccess problem. (I say "unlikely"... a redirect obviously goes via the browser to trigger a second request, but for this to affect one browser and not another is doubtful.)
    – MrWhite
    Apr 14, 2016 at 7:45
  • Are you able to test the site yourself in these problematic browsers? Do you do any browser sniffing?!
    – MrWhite
    Apr 14, 2016 at 7:58
  • Also, please consider that you may not actually have a problem. Google's metrics are often misleading. In this case, it is quite possible that just one or a few users had an issue that has skewed the average. I have seen this before in Googles similarly represented metrics. Also, keep in mind that this can also be a badly coded bot of some kind. It may not always really be a browser. Google has no real way of knowing in this case. You could always use Piwik to analyze your log files. This should help make sense of the metrics. Take Google with salt.
    – closetnoc
    Apr 14, 2016 at 14:35
  • Stuff like this is almost always the result of 1 or 2 big outliers. Try drilling down to view Chrome/Windows over the course of the last month. Apr 14, 2016 at 18:54

1 Answer 1


Briefly as you mention your .htaccess file if you have access to the vHost file it is better to shift these declarations into the vHost file as Apache needs to check the .htaccess file for every request whereas in the vHost file the commands are loaded to memory on startup the same as the rest of the vHost settings. Having said that unless you have a .htaccess conditional statement that only affects Safari and Chrome browsers the .htaccess file can't be the issue as it would affect all browsers the same way and impart around the same amount of delay in the time to first byte.

You need to be careful about how you use Google's metrics in Google Analytics as Google uses sampling, and in any sampling situation because of the "random" data selections high outliers in the data (data that is greatly different to the rest of the data) can throw the figures way out. As an example even if only a few users with those browsers had issues (such as badly configured browser extensions) that can throw the data wildly out of wack, and that significant a variation (especially given most browser configurations will timeout the connection well before the 80+ second mark you cite tends to reinforce that to me. If you are concerned you can run performance tests yourself by doing a series of rapid page loads using the offending browsers to see if the delay is really that high or if it may have been unique to very few users. The trick here is that due to the high market saturation (browser-wise) of Safari and Chrome there is a much higher chance of data outliers.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.