WebPagetest Forums

Full Version: Best ways to cut down TTFB
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Hello All,
I'm curious on how to cut down on "Time to First Byte" for static files.

ex) #13

http://www.webpagetest.org/result/111129...1/details/

In the waterfall it shows about 122 ms.

If you put in the URL alone to test you get 67 ms.

I understand that multiple things can be affecting it, but just curious on your thoughts on how to improve the time to first byte for static content when requesting a page with a lot of static content.

Thanks in advance.

Regards,
TRX
That could be a function of the browser just being busy doing layout and other stuff or of the server being busy (my guess is on the browser side). You can do a test run with a tcpdump to verify the timings at the network layer but if it's in the browser you pretty much just have to try and limit things like reflows (provide sizes in the html for all of your image elements), javascript that executes during load, etc.
It looks like the bad TTFB score comes mostly from the main page (item #2) with a TTFB of 536ms.

The TTFB for #13 varies a bit, and 122ms and 67ms are in the normal range:
http://www.webpagetest.org/result/111129_68_2BCY7/
[Load the image 10 times. Notice that the first run is slower than the others.]

Looks like you could get a big time savings by eliminating the initial redirect and figuring out why the main page takes so long to serve.

-slamm


(11-30-2011 07:32 AM)trx Wrote: [ -> ]Hello All,
I'm curious on how to cut down on "Time to First Byte" for static files.

ex) #13

http://www.webpagetest.org/result/111129...1/details/

In the waterfall it shows about 122 ms.

If you put in the URL alone to test you get 67 ms.

I understand that multiple things can be affecting it, but just curious on your thoughts on how to improve the time to first byte for static content when requesting a page with a lot of static content.

Thanks in advance.

Regards,
TRX
Slamm,
#2 is a dynamic page and that is why it takes that long. My understanding is, a dynamic page should take from 200-500 ms TTFB. Would you agree? I'll see what we can do to optimize that request.

Regards,
TRX
"should" is relative :-)

Any savings off of the base page will go directly towards the load time and to improving your server utilization so faster is always better but you have to see if it is worth the effort. Depending on the application you can get those times to be almost as fast as static content but it takes quite a bit of effort and dedicated servers to have full control over it.

Eliminating network latency, I have my average response time for dynamic content running ~10-15ms but that's on a dedicated server with Nginx+PHP-FPM+APC, gobs of RAM and SSD storage.
Thanks. So a quick recap to identifying TTFB and trying to optimize it.

1) Look at results and see which request has a high TTFB respectively.

Dynamic content - 200ms-500ms
Static content - under 100 ms

2) Apply the rules to try to optimize the TTFB:

If your TTFB for static content is high, then you may have reached the hardware/configuration limits of your server.

If your TTFB for your static content is low but dynamic content is high, then your application or server configuration may be to blame.

If you find a server with little load and fast static content but slow dynamic content, configuration changes to Apache/IIS/etc., MySQL/SQL/tc. and PHP/etc. may help. If these configuration changes do not help, then the bottleneck may be in the code itself. In this case, you may need to consider profiling your application.

Let me know your thoughts on the resolving slow TTFB issues.

Regards,
TRX
Looks like something we could put into a flow chart. May take a crack at that :-)
Reference URL's