1

I ran a few tests on my website at webpagetest.org and while the Time to First Byte is under 200ms, it seems that in all tests I have run in different browsers at different locations, the page is presented to the screen much later after the first HTML page has been completely downloaded.

I ran a test in firefox from New York using their native connection and it shows that rendering starts at 600 ms yet the first downloadable byte (TTFB) is ready as of 100 ms:

See: http://www.webpagetest.org/result/150614_G7_KR7/1/details/

I then proceeded to try chrome from the same computer with other settings the same. TTFB is roughly the same however the rendering starts at 350 ms:

See: http://www.webpagetest.org/result/150614_56_KTJ/1/details/

I decide then to try IE 11 from California with other settings the same. TTFB is a bit longer as expected, yet the rendering refuses to start before 600 ms:

http://www.webpagetest.org/result/150614_T3_KYC/

My pages are served gzipped and I flush the buffers between outputting the HTTP headers and outputting the actual webpage data.

I'm gonna look into increasing the compression level but if there is anything else I can do server-side to see the first loaded page right away instead of waiting until the browsers decide when they are good and ready to display it.

Also, if you see the filmstrip view of each test, you'll see my problem dead-on because nothing appears on screen before 500 ms.

I do apologize if this question ends up being placed on-hold, but I feel this is an issue that needs a solution, and I'm sure at least someone else experienced similar results with their websites.

Improve this question
7
  • 500ms is half a second. You cannot even blink that fast! The TTFB metric you cite includes DNS lookup and network lag time. 500ms is really not bad over the internet. I actually prefer to ignore the TTFB metric because it can be misleading. I worry about the time it takes to download the entire HTML page and then any resource after that. You cannot really speed up DNS except where the DNS is particularly slow as well as any latency that a user would have. What I am saying is this is one metric where most of it is out of your control. If your site is fast enough, do not sweat the small stuff.
    – closetnoc
    Jun 14, 2015 at 16:21
  • I have to because it tends to make a difference in my earnings. Google likes sites that have small TTFB. since making the output flush after the headers, my income each day is at least a few cents by mid afternoon as opposed to zero to one cent.
    – Mike -- No longer here
    Jun 14, 2015 at 16:41
  • Google measures site times based upon the total download times of all sites- it is like grading on a curve. Any site that is within normal ranges are not effected at all and any site that is slow is only effected if it is very slow. You are not likely within that effected range. One of the reasons why I look at page load times more than TTFB is because this is where you can really make a difference for the user. Even a site with a longer TTFB can be faster than most sites. The largest factor for TTFB tends to be DNS/domain name resolution.
    – closetnoc
    Jun 14, 2015 at 16:51
  • DNS resolution is what I need to work on since that takes up to 50% of my TTFB
    – Mike -- No longer here
    Jun 14, 2015 at 20:50
  • I am not sure who you use, but consider a DNS host with a solid reputation. Most big name registrars have decent reputations of course, but I cannot swear by any of them. If you consider a DNS host, see what guarantee they can give you.
    – closetnoc
    Jun 14, 2015 at 22:59

1 Answer 1

Reset to default
3

Interesting case, since the page is fairly simple. Firstly, I'd agree with closetnoc's comment that your page is already pretty fast - it's clear you've spent some time working on speed, so any further gains will be micro-optimizations at best. (Faster DNS would certainly help though, as you said.)

My pages are served gzipped and I flush the buffers between outputting the HTTP headers and outputting the actual webpage data

I'm assuming by this you mean you're flushing after the end of the HTML <head> section? There's not much benefit to sending the browser HTTP headers only.

'Flush early' is given as general advice since it lets browsers start grabbing external resources specified in the <head> section whilst they wait for the rest of the HTML page to be downloaded. But since you don't have any external resources linked in the <head>, and your page is being downloaded in 10ms, I really wouldn't worry about this.

I'm gonna look into increasing the compression level

Your HTML page is 5Kb (compressed). Increasing the compression level would save you a few bytes at best, and the increased CPU time required on the server side may well cause this to have a negative effect.

Assuming you do want to try and improve this further, from the CPU utilization graph on your webpagetest results you can see that the browser is busy "doing stuff" between receiving the HTML page and rendering, and since there aren't any external resources it's waiting for, all you can do is try and make the page simpler to render. There are two things I'd suggest:

  1. You have a lot of CSS for a page with a pretty simple layout (it takes up about 50% of the HTML source). Perhaps this can be simplified? Once upon a time guides would have said take a look at using more efficient CSS selectors (avoiding things like #mp DIV DIV A and #mp DIV DIV), but this doesn't seem to be much of an issue these days. (And I see that Page Speed Insights no longer suggests looking at this.)

  2. You have a couple of lines of inline javascript, the purpose of which seems to be allow the Google ads to load as early as possible (invisibly), and then be moved into the right position. Instead, it might be better to split your Google ads JS so that the adsbygoogle.js async call is in the <head> section, and the ads <ins> tag is where you want them to render. Then you could get rid of your inline JS and the related CSS rules completely.

Improve this answer
3
  • Very thoughtful answer!!
    – closetnoc
    Jun 15, 2015 at 0:02
  • I think at one point I moved part of adsense call to the head section once and that resulted in zero income but I wasn't sure if other factors came into play at that point. Also, I made the flush happen before the first byte (meaning before the <DOCTYPE is printed). I'll look into your suggestions and see what happens.
    – Mike -- No longer here
    Jun 15, 2015 at 0:26
  • I also have to watch my selectors because If I keep using short-hand selectors then I'll have to waste at least 6 bytes per selector. Some CSS is long because I utilize CSS sprites and the word "background" takes up alot of bytes in comparison to other CSS code.
    – Mike -- No longer here
    Jun 15, 2015 at 0:29

Your Answer

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

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