FBT over 3s - slows down site performance

Hi,

We have an issue where our FBT (First Byte Time) is around 4s, which seems rather long. Very interesting though is when you look at the following tests using http://www.bytecheck.com/:

  1. FBT for opgroeigids.nl (non-www) - FBT = 0.324s
  2. FBT for www.opgroeigids.nl - FBT = 3.977s

It seems that for some reason the ‘www’ adds around 3s, which is not normal.

Now we have been working with SiteGround over the last few days trying to resolve this and their latest message said the following:

“After examining your case thoroughly, I have come to find out that the issue appears the caused by the .htaccess protection rules for opgroeigids.nl.” - SiteGround

The tests were done by replacing the htaccess maker .htaccess file by standard Joomla .htaccess file. We also removed our added lines from the field in htaccess maker.

Can you please assist us to pinpoint the 3s delay on our FBT time, as this is a serious issue when loading our site.

Also see the following tests:

  1. Website Speed Test | Pingdom Tools - 3.48s wait

  2. http://www.webpagetest.org/result/140422_X3_9CY/ - 3201 ms First Byte Time

  3. http://developers.google.com/speed/pagespeed/insights/?url=www.opgroeigids.nl&tab=desktop

I would really appreciate your help on this strange issue.

Thanks,

Andrew

I can tell you right off, loading 2.6 MEGAbytes on browsers makes for a slow site and for slow FBT. It’s also absolutely a bandwidth killer. Imagine 2.6 megabytes times your traffic. 1000, 100,000, a million pageloads daily?

You need to trim the fat and try to get under 1 megabyte. You’ll see immediate improvement in FBT and overall load time.

Show me a fat site and I’ll show you a slow site. Every time.

Your biggest offenders are the images, look at them all here. All the JPEGs need to be made progressive and be optimized, and that massive banner PNG needs to be converted to progressive JPG to save a whopping 300kb right there by itself. (Item #73.)

Get rid of the custom fonts - most browsers won’t display them but they load anyway - this is 9 percent of your pageload, wasted!

Do you really need the flash objects? 3 percent of your pageload.

You are javascript HEAVY with it being 42 percent of your load - that stuff only displays on browsers with javascript enabled - do you really need all of it?

Finally, do you have more than one scale in your bathroom? Do you weigh yourself on 4 or 5 scales, choosing the number you like best? Or are you more scientific about it, and just stick to one scale?

Use just one web page test and make your site score well on that, multiple tests from different sites just muddy the waters. I guarantee you that if you get straight A scores on Meenan’s test, you’ll score good everywhere.

This is the one and only test I use, fast cable connection, IE 10 in Dulles VA. IE 10 because it is hardest to satisfy and support, Dulles because it is consistent and always readily available for tests. Your distance from it and the hops you take to get there aren’t as relevant as people think.

You lose all scientific method and objectivity using a scattershot test method. Concentrate on the items I have pointed out here and you’re on the road to improvement.

This is all about striking that balance between form and function. Right now you are sacrificing function, for form.

Contrast these two tests…

  1. http://www.webpagetest.org/result/150509_GB_2EX/1/details/

  2. http://www.webpagetest.org/result/150509_GD_2SA/1/details/

Notice the redirect speed time eaten up in #1 (your site) which is likely due to the redirection scheme you’re using.

The way I get sub 100ms times on these is to use fast + internal apache redirects.

Try this + see if a chunk of your redirect time disappears. In your site apache.conf file do the following redirects if your terminal (final) target is the bare (non-www) domain. Switch sense of redirects if you’re targeting www.

For http://www.opgroeigids.nl + http://opgroeigids.nl + https://www.opgroeigids.nl
Redirect permanent / https://opgroeigids.nl

This will drop your redirect time between non-SSL → SSL protocols to below 100ms for each level of redirect… so… best to redirect non-SSL www + bare site URL both to your terminal (final) SSL URL, which will either be https://www.opgroeigids.nl or http://opgroeigids.nl as you desire.

So avoid any .htaccess or .php or .cgi or any other redirect scheme.

Stick with internal Apache (or whatever server you’re using) redirects that run inside the server.