Verry long First Byte Time (18 seconds)

[ultimatia]

Hello,

First of all, sorry for my bad english.

It takes a very long time before my website is loading (sometimes around 15 seconds). In google Developer Tools > Network the TTFB takes 18.6 seconds like you can see in the attachement.

The FBT is variable, sometimes better than other times but always to slow (never less than around 2 seconds).

I tested also on Webpagetest.org and the FBT time is around 2 seconds (grade F)

I dont think the server is causing this problem: when I load a emty page the FTB is very fast (grade A).

Does someone has an idea what is causing this problem and how I can fix it?

Thanks alot for your help and best regards,

Ultimatia

[iSpeedLink.com]

When looking at TTFB there are, in your case, 3 events included.
[list]
[]DNS Lookup
[]Initial Connection
[*]Waiting for First Byte
[/list]

You are correct, the server is NOT the problem. Your server is excellent, one of the fastest I have seen @12,550,376 Bps.

After Initial connection the server retrieves your webpage. In your case your index page is generated by PHP.

The PHP programming is the problem.

PHP should not be switching between HTML and PHP mode, the entire page should be echoed by PHP. HTML can be echoed in php with heredoc syntax:
[php]echo <<<EOT
HTML
EOT;[/php]

Rather than:
[php]
HTML
[/php]

Right after the is echoed you should do a flush buffer. The most common way to do this in PHP is using ob_start().

I find flushing the buffer works best when using the ob_gzhandler. This is because PHP then controls the gzip compression. When gzip is left to the server there is no practical way to flush the buffer from PHP.

Similar to this:
[php]

<?php ob_start("ob_gzhandler"); echo <<<EOT ... EOT; ob_flush(); [/php] I include the tag so the Browser knows it can process the section and begin to render the page. Before this flush there should be no lengthily computational code or database queries. As soon as the ob_flush() is executed, the server begins transmitting the HTTP Response (First Bytes). Your PHP does not send the First Byte until the PHP script completes. Why it sometimes takes 18+ seconds to execute the PHP script is beyond the scope of this post. The thing is by first transmitting the section before executing any computational code or database queries, the Browser will be busy processing the CSS and JS in the section while the subsequent PHP is being executed.. This will with no doubt cure the long TTFB. Then you can get your in order (e.g. all CSS and fonts (.woff) should be linked in before any JS. When possible (most of the time) the JS should be located immediately before the close of the body and html . I find the overhead of font files to not be worth their value. I have attached a screenshot of the results of my testing. [attachment=572]

[GreenGecko]

Hmm… defining server performance by it’s network speed is not the best. The server is at fault, and for most of us mortals ( on ADSL… ) is pretty irrelevant.

Also, your coding suggestions are based on absolutely no solid evidence. They also take into no account any of the caches that may be in place.

A quick test at cable speeds from Ireland ( it’s a node I know, and close to your target audience ) shows a TTFB of c. 1.5s which isn’t brilliant ( speed it important with an eCommerce site! ), but is a good starting point.

http://www.webpagetest.org/result/160223_P6_13D5/

I see that it’s an OpenCart / php 5.5 / nginx site, so there are things you ( or hexweb ) can do to improve things.

Basically:

MySQL wants to be configured with loads of memory to cache stuff. Also, it needs to be at a minimum version of 5.6.

PHP is running in FPM mode ( or at least I hope so, and it’s not one of these ‘apache behind nginx’ setups ), so give it a decent opcode cache, and play with alternatives: PHP 5.6 / 7 / hhvm to see if it improves things.

nginx can be sped up quite a lot, the open file cache can help a lot amongst many things.

After that, look ad reducing the amount of content that you’re delivering to the client. I see that there are a lot of web fonts included ( including one that doesn’t exist ). Do you need them all? As many are from 3rd party hosts you can’t control their performance… always a worry. Also, it should be possible to shrink the size of the images in use with no reduction in quality - a 1.4MB homepage shrinking to 500kb is good, although as the expires headers are set up, you’re only addressing the first visit to the site.

If you can get some profiling in place - say (briefly) install new relic - you’ll get some idea on where the bottlenecks are. Because you’ve got a LEMP stack, it does make it easier to identify the bottleneck. If overall PHP performance is the problem, then you need more CPU power ( the newer E5 Xeons are a lot faster due to their large on-die cache ), databases usually speed up with sensible use of extra memory to improve caching ( there are scripts out there on the net to aid in tuning it, don’t try and re-invent the wheel here! ).

Only then is it time to start pulling the code apart…

Cheers / MVG

Steve