Current time: 12-17-2017, 12:15 PM Hello There, Guest! (LoginRegister)

Post Reply 
 
Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
First Byte Time “FBT” findings and research results
07-23-2015, 11:26 PM
Post: #1
First Byte Time “FBT” findings and research results
First and foremost I hope this helps some others, I find it very important to share knowledge that will help others to improve their Web sites on the Internet.
 
I have been scratching my head trying to figure out why I was receiving an “F” rating on http://www.webpagetest.org for First Byte Time “FBT”. After some research and additional testing on http://www.shoeshow.com I have come to the following conclusions:
 
Reasons why First Byte Time takes so long
1) Number of requests/responses needed to build the page
2) Does the page have a lot of Dynamic content on the page (aka how many database calls are going back and forth for data)
3) Size of the overall page
4) Size of CPU and MEMORY of the HOSTING SERVER. The more powerful the SERVER the faster processing you will receive.
5) Do you have a VM Server or a Dedicated Server
 
My test sample was for the home page of http://www.shoeshow.com I got an “F” for FBT every time, that is because this page has a lot of dynamic content and unless I dissect and rebuild this page it will continue to receive an “F” although the overall page is loading in under 2 sec. However, If I go to https://www.shoeshow.com/reward-points it gets a “B” because there is very little dynamic or programming on that page and not many images. Finally when I run our https://www.shoeshow.com/404.aspx we get an “A” because there is no images and no coding.
 
My overall opinion is that FBT is important, but can also be a false/positive.
Find all posts by this user
Quote this message in a reply
07-24-2015, 06:33 AM
Post: #2
RE: First Byte Time “FBT” findings and research results
OK, you've identified the problems, but haven't really addressed how to improve stuff...

There are major two avenues you need to investigate to improve the TTFB performance of your site:

a) Server configuration
b) Code quality

The basic mantra for tuning a server is to keep disk access to a minimum as it's really, really slow. This means using memory as possible: database caches work well ( because the vast majority of your accesses are read only ), place heavily used files on tmpfs partitions, and so on. Make sure your server-side processing is cached as much as possible - APC for olderr versions of PHP can make a big difference. If your server has plenty of spare memory, then it will be used to buffer disk IO which will also help.

The only real way to identify bottlenecks is to monitor the server in production use: find one, fix it, and there will ( *always* ) be another to identify. Eventually you'll get to a place where only a 'hardware' upgrade will help. That's when you've won. For now. Don't forget things will change as database tables fill, the site changes, etc.

Code quality is something that is falling all the time IMO. Not only is code poorly written, leading to poor performance, but in this plugin age, one from Joe Bloggs may cripple one written by Bill Smith, which is really annoying. Best plan is to use a test site, remove all plugins, and profile performance as they are added back in. Who cares if it looks a mess while you're doing it - nobody is looking!

You normally find that the core CMS is clean and fast - this is the stuff that's written by people who fully understand the codebase. Plugins on the other hand have far less in terms of quality control!
Find all posts by this user
Quote this message in a reply
07-25-2015, 01:06 PM (This post was last modified: 07-25-2015 01:32 PM by Anton Chigurh.)
Post: #3
RE: First Byte Time “FBT” findings and research results
I put forth much of this same information some time back and was lambasted. Even though I was able to prove it.

I've also found and it is especially true with your site you mention, shoeshow dot com, that the TARGET first byte time is just ridiculous and this skews the grade. The TARGET for that site is 87ms. That's unattainable and nonsensical.

I find this really low TARGET FBT happens on every site that uses a CDN such as cloudflare and Akami, which I see the subject site does use. I believe it is something with the testing that if it detects a CDN it assigns the low target because there is some assumption the CDN improves performance so it tries to grade you on a negative curve. The "false positive" you mention.

If you use a CDN you pretty much have to dismiss poor FBT grades because the TARGET FBT you get is just silly.

And yes, if you have a bloated page (such as this 2.6 megabyte one) you're going to have a poor performing page. It doesn't load in 2 seconds - it might for you because of your caching - but in tests, no.

http://www.webpagetest.org/result/150725_PG_4FV/

You can shave 1,529.9 KB (That's 1.5 megabytes) off this bloated page and greatly improve performance, just by optimizing your jpeg images.

Quote:Compress Images: 32/100

2,255.4 KB total in images, target size = 725.4 KB - potential savings = 1,529.9 KB

FAILED - (547.5 KB, compressed = 117.5 KB - savings of 430.0 KB) - https://www.shoeshow.com/FS/COVER/1462/0...x_0720.jpg
FAILED - (441.5 KB, compressed = 85.3 KB - savings of 356.1 KB) - https://www.shoeshow.com/FS/COVER/1461/0...c_0720.jpg
FAILED - (441.8 KB, compressed = 91.7 KB - savings of 350.1 KB) - https://www.shoeshow.com/FS/COVER/1460/0...4_0720.jpg
FAILED - (321.4 KB, compressed = 94.4 KB - savings of 227.0 KB) - https://www.shoeshow.com/FS/COVER/1467/s...e_0724.jpg
WARNING - (150.5 KB, compressed = 105.0 KB - savings of 45.5 KB) - https://www.shoeshow.com/FS/COVER/1453/0...s_0706.jpg
FAILED - (61.4 KB, compressed = 23.5 KB - savings of 37.9 KB) - https://www.shoeshow.com/framework/image...39x361.jpg
WARNING - (150.8 KB, compressed = 114.1 KB - savings of 36.8 KB) - https://www.shoeshow.com/FS/COVER/1459/6...78x573.jpg
WARNING - (104.9 KB, compressed = 84.1 KB - savings of 20.7 KB) - https://www.shoeshow.com/FS/COVER/1457/0...d_0706.jpg
FAILED - (9.7 KB, compressed = 2.5 KB - savings of 7.2 KB) - https://www.shoeshow.com/FS/Products/133...ges_01.jpg
FAILED - (8.3 KB, compressed = 2.2 KB - savings of 6.1 KB) - https://www.shoeshow.com/FS/Products/133...ges_01.jpg
FAILED - (6.5 KB, compressed = 1.6 KB - savings of 4.8 KB) - https://www.shoeshow.com/FS/Products/133...ges_01.jpg
FAILED - (5.8 KB, compressed = 1.8 KB - savings of 4.0 KB) - https://www.shoeshow.com/FS/Products/175...ges_01.jpg
FAILED - (5.3 KB, compressed = 1.7 KB - savings of 3.7 KB) - https://www.shoeshow.com/FS/Products/778...ges_01.jpg
And in this it is demonstrated that CDNs do not improve performance, they do not optimize your site, they merely deliver your un-optimized content and all the bloat, from a location ostensibly nearer to the user than your host server would. It's not a magic bullet for performance. Cutting the bloat, is.

You should get off Akami's nameservers then run a series of tests without it, and be shocked at the difference. Then optimize these images and lose the 1.5 megabytes of unnecessary bloat.
Find all posts by this user
Quote this message in a reply
07-28-2015, 12:19 AM
Post: #4
RE: First Byte Time “FBT” findings and research results
Anton any compression software that you recommend. I am on a Windows OS. I have used Shrink-O-Matic. Please also understand I have expressed this issue with our Visual Team and we are in the process of getting them to start running all images through - https://imageoptim.com/ (They are on MACs). Thanks for the feed back.

(07-25-2015 01:06 PM)Anton Chigurh Wrote:  I put forth much of this same information some time back and was lambasted. Even though I was able to prove it.

I've also found and it is especially true with your site you mention, shoeshow dot com, that the TARGET first byte time is just ridiculous and this skews the grade. The TARGET for that site is 87ms. That's unattainable and nonsensical.

I find this really low TARGET FBT happens on every site that uses a CDN such as cloudflare and Akami, which I see the subject site does use. I believe it is something with the testing that if it detects a CDN it assigns the low target because there is some assumption the CDN improves performance so it tries to grade you on a negative curve. The "false positive" you mention.

If you use a CDN you pretty much have to dismiss poor FBT grades because the TARGET FBT you get is just silly.

And yes, if you have a bloated page (such as this 2.6 megabyte one) you're going to have a poor performing page. It doesn't load in 2 seconds - it might for you because of your caching - but in tests, no.

http://www.webpagetest.org/result/150725_PG_4FV/

You can shave 1,529.9 KB (That's 1.5 megabytes) off this bloated page and greatly improve performance, just by optimizing your jpeg images.

Quote:Compress Images: 32/100

2,255.4 KB total in images, target size = 725.4 KB - potential savings = 1,529.9 KB

FAILED - (547.5 KB, compressed = 117.5 KB - savings of 430.0 KB) - https://www.shoeshow.com/FS/COVER/1462/0...x_0720.jpg
FAILED - (441.5 KB, compressed = 85.3 KB - savings of 356.1 KB) - https://www.shoeshow.com/FS/COVER/1461/0...c_0720.jpg
FAILED - (441.8 KB, compressed = 91.7 KB - savings of 350.1 KB) - https://www.shoeshow.com/FS/COVER/1460/0...4_0720.jpg
FAILED - (321.4 KB, compressed = 94.4 KB - savings of 227.0 KB) - https://www.shoeshow.com/FS/COVER/1467/s...e_0724.jpg
WARNING - (150.5 KB, compressed = 105.0 KB - savings of 45.5 KB) - https://www.shoeshow.com/FS/COVER/1453/0...s_0706.jpg
FAILED - (61.4 KB, compressed = 23.5 KB - savings of 37.9 KB) - https://www.shoeshow.com/framework/image...39x361.jpg
WARNING - (150.8 KB, compressed = 114.1 KB - savings of 36.8 KB) - https://www.shoeshow.com/FS/COVER/1459/6...78x573.jpg
WARNING - (104.9 KB, compressed = 84.1 KB - savings of 20.7 KB) - https://www.shoeshow.com/FS/COVER/1457/0...d_0706.jpg
FAILED - (9.7 KB, compressed = 2.5 KB - savings of 7.2 KB) - https://www.shoeshow.com/FS/Products/133...ges_01.jpg
FAILED - (8.3 KB, compressed = 2.2 KB - savings of 6.1 KB) - https://www.shoeshow.com/FS/Products/133...ges_01.jpg
FAILED - (6.5 KB, compressed = 1.6 KB - savings of 4.8 KB) - https://www.shoeshow.com/FS/Products/133...ges_01.jpg
FAILED - (5.8 KB, compressed = 1.8 KB - savings of 4.0 KB) - https://www.shoeshow.com/FS/Products/175...ges_01.jpg
FAILED - (5.3 KB, compressed = 1.7 KB - savings of 3.7 KB) - https://www.shoeshow.com/FS/Products/778...ges_01.jpg
And in this it is demonstrated that CDNs do not improve performance, they do not optimize your site, they merely deliver your un-optimized content and all the bloat, from a location ostensibly nearer to the user than your host server would. It's not a magic bullet for performance. Cutting the bloat, is.

You should get off Akami's nameservers then run a series of tests without it, and be shocked at the difference. Then optimize these images and lose the 1.5 megabytes of unnecessary bloat.
Find all posts by this user
Quote this message in a reply
07-28-2015, 05:56 AM
Post: #5
RE: First Byte Time “FBT” findings and research results
(07-28-2015 12:19 AM)moojjoo Wrote:  Anton any compression software that you recommend. I am on a Windows OS. I have used Shrink-O-Matic. Please also understand I have expressed this issue with our Visual Team and we are in the process of getting them to start running all images through - https://imageoptim.com/ (They are on MACs). Thanks for the feed back.
WPT actually does all the compression for us. Click on "View All Images" HERE the link is directly under the bottom of the water fall. From there you click on "Analyze JPEG" and it gives you three versions of the image.
Find all posts by this user
Quote this message in a reply
07-29-2015, 12:46 AM
Post: #6
RE: First Byte Time “FBT” findings and research results
Anton, you the MAN --- I did not know that. And KNOWING IS HALF-THE-BATTLE --- G.I. JOE... LOL.


(07-28-2015 05:56 AM)Anton Chigurh Wrote:  
(07-28-2015 12:19 AM)moojjoo Wrote:  Anton any compression software that you recommend. I am on a Windows OS. I have used Shrink-O-Matic. Please also understand I have expressed this issue with our Visual Team and we are in the process of getting them to start running all images through - https://imageoptim.com/ (They are on MACs). Thanks for the feed back.
WPT actually does all the compression for us. Click on "View All Images" HERE the link is directly under the bottom of the water fall. From there you click on "Analyze JPEG" and it gives you three versions of the image.
Find all posts by this user
Quote this message in a reply
07-29-2015, 05:03 AM
Post: #7
RE: First Byte Time “FBT” findings and research results
Anton, why would I be getting 0 now? Is it because the images are cached?



(07-29-2015 12:46 AM)moojjoo Wrote:  Anton, you the MAN --- I did not know that. And KNOWING IS HALF-THE-BATTLE --- G.I. JOE... LOL.


(07-28-2015 05:56 AM)Anton Chigurh Wrote:  
(07-28-2015 12:19 AM)moojjoo Wrote:  Anton any compression software that you recommend. I am on a Windows OS. I have used Shrink-O-Matic. Please also understand I have expressed this issue with our Visual Team and we are in the process of getting them to start running all images through - https://imageoptim.com/ (They are on MACs). Thanks for the feed back.
WPT actually does all the compression for us. Click on "View All Images" HERE the link is directly under the bottom of the water fall. From there you click on "Analyze JPEG" and it gives you three versions of the image.
Find all posts by this user
Quote this message in a reply
07-29-2015, 05:17 AM
Post: #8
RE: First Byte Time “FBT” findings and research results
(07-29-2015 05:03 AM)moojjoo Wrote:  Anton, why would I be getting 0 now? Is it because the images are cached?
Not sure what you're asking. I am still seeing the F grade for your images, and still seeing over 2.8 megabytes of pageload.

http://www.webpagetest.org/result/150728_SH_12G5/
Find all posts by this user
Quote this message in a reply
07-29-2015, 12:58 PM
Post: #9
RE: First Byte Time “FBT” findings and research results
I keep stressing that the size of the images makes absolutely no difference to the TTFB. It's just payload, whereas the TTFB is concerned with the delivery of the html framework that all these images are placed.

In addition, CloudFlare IS NOT A CDN. It is a proxy server, and mixing the two will always lead to complications. I see that you're not using it BTW. Just commenting on those who don't see the distinction.

I would add in a rule at webserver level to shortcut the redirection from shoeshow.com to http://www.shoeshow.com. This is slow when done in software.

Apart from that I can't comment much, as I know nothing of tuning websites on a Windows server, or what CMS the site is written in. For something like this, I'd use Magento CE...
Find all posts by this user
Quote this message in a reply
07-29-2015, 01:41 PM (This post was last modified: 07-29-2015 01:46 PM by Anton Chigurh.)
Post: #10
RE: First Byte Time “FBT” findings and research results
(07-29-2015 12:58 PM)GreenGecko Wrote:  I keep stressing that the size of the images makes absolutely no difference to the TTFB. It's just payload, whereas the TTFB is concerned with the delivery of the html framework that all these images are placed.
So that, with everything else the same and we have poor FBT, when we test a page in our site with no images and not a lot of "payload" maybe 200kb or so, magically we get greatly improved FBT. Every time.

No one is saying the size of images are related to FBT. Bloat is a separate consideration but it is a much more important one than FBT.
Quote:In addition, CloudFlare IS NOT A CDN.
Tell Patrick that. WPT scores CF as a CDN and it is considered a CDN for the context of the testing. Sites using Cloudflare, when you look in the test results to see what CDNs it has, you see "CDNs used; Cloudflare." Additionally, when you look up CDN most anywhere, CF is listed:

https://en.wikipedia.org/wiki/Content_de..._providers

I think it is okay to call it a CDN if Patrick and the rest of the world does.

Not sure how many times I need to demonstrate that getting rid of excess bloat helps the FBT as well as the rest of the performance measurements. I've only done it for dozens of sites.
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 1 Guest(s)