First Byte Time “FBT” findings and research results

[quote=“GreenGecko, post:17, topic:9482”]

Well, this is a Magento demo site. What CMSes have you optimised, and where are the examples? You’re coming over as talking a good fight at the moment.
[/quote]Fighting what? This idea that every site needs a CDN? I’m not even sure what you’re trying to argue.

I could link you to literally dozens of sites I have optimized but what really is the point? While I’m here legitimately helping people, you’re just being argumentative, muddying the waters and giving mostly advice the basic site owner can’t even follow. It’s like you are more interested in showing off your tech acumen rather than providing actual help.

Newsflash - nobody cares about your advanced knowledge, they just want help understanding WPT, and how to use the tools it provides, and mostly need just the most basic help and advice. The essential stuff they can actually do. That’s what I volunteer my time, doing.

[quote=“Anton_Chigurh, post:21, topic:9482”]

And what do I gain from ‘showing off’ Anton? It costs time and effort to respond, and I really don’t need any more work that’s for sure. I just get hacked off when people spout absolute crap which often requires Scotty changing the laws of physics.

This thread is about the TTFB of a site. For all practical purposes, payload like images, css and js have no effect on this, as they are loaded after the pages html, delivery of which is what we’re talking about*. And yet you tell us differently, but provide no evidence.

SysAdmin isn’t hard. It just requires information, logic and time to digest and analyse, and these are the skills required to tune a website ( whether they’re done for you on a shared host, or you have control of them is a separate question ). Gut feelings are a good starting point but, like any hypothesis, it needs analysis, investigation and proof to be of any value. I’m not showing off, I’m attempting - by example - to get you to complete this process. Something you’re refusing to do.

I certainly don’t know everything - I left the Dunning-Kruger part of my career around a long time ago - and am still learning about getting the best out of linux servers 3 decades after starting in the field. For me responding to these queries is pay back time for an industry that’s looked after me quite well over the years.

*unless you’re obviously gaming the system.

It seems like Anton is suggesting that reducing bloat could improve TTFB but doesn’t actually know why, even though he’s seen it happen in the past.

No one else thinks it’s possible because the server can’t possibly know what assets are even going to be called until the HTML requests them which is after FirstByte.

IMO he’s right though, If the same resource is serving pages and assets.

The bloat from YOUR requests wouldn’t affect your TTFB but the bloat from the rest of the traffic on the site could be reducing capacity and affecting your TTFB.

[quote=“GreenGecko, post:22, topic:9482”]

I originally posted this back in May of 2015, but I am back to provide more insight.

(Warning this only applies to Microsoft .NET) unsure about PHP or other web technologies.

Setting the Connection Limit
This section explains how to increase the number of simultaneous connections between
the client and WEBSERVER.

By default (.NET), you can create only two simultaneous connections to an HTTP server.

By increasing the number of connections, you can avoid a backlog of requests during times of
very high transaction volume. Microsoft recommends for the connection limit a value that
is 12 times the number of CPUs. For example, if you have two CPUs, you can set the
connection limit to 24. To determine the optimum setting for your application, make sure to
run performance tests.

Examples
You can increase the number of connections in many ways, for example by using an
application- or server-specific configuration file where you can change the setting for a
single or for all hosts. The examples below describe briefly some of the methods that you
can use to increase connection limits.

When set to a value other than -1, the connectionLimit setting in the client
increases the limit for the host where you are sending the request by executing these
statements on your behalf:

You can set the connection limit by using .NET's tag. In this example, the connection limit for WEBSERVER's test and production hosts is 12 while the limit for all other hosts is 2: ServicePoint sp = ServicePointManager.FindServicePoint(uri); sp.ConnectionLimit = config.ConnectionLimit;

<system.net>




</system.net>

DefaultConnectionLimit
You can set the connection limit for all hosts to which your application is connected before
a connection is made by using the following line in your start-up code:
ServicePointManager.DefaultConnectionLimit = your_value_here;

References
For more information on these and other methods to increase the connection limits, see
the following Microsoft documentation: Managing Connections in the .Net Framework Developer’s Guide ([url=http://msdn2.microsoft.com/en-us/library/7af54za5.aspx]http://msdn2.microsoft.com/en-us/library/7af54za5.aspx[/url]).

Also note we increase the CPU and RAM raised FTFB from an F to C, but after this change it is now a B.

[quote=“Gnaser, post:23, topic:9482”]
It seems like Anton is suggesting that reducing bloat could improve TTFB but doesn’t actually know why, even though he’s seen it happen in the past.

No one else thinks it’s possible because the server can’t possibly know what assets are even going to be called until the HTML requests them which is after FirstByte.

IMO he’s right though, If the same resource is serving pages and assets.
[/quote]And happily, I was finally able to prove this. It’s a fact.

Read here. Then read here.

The only thing going on besides the “handshake” during the FBT, is that in request #1 the server is composing the executable page source code and sending it to the browser, which downloads it then executes it. Then the content starts loading.

The more requests you have, the longer it takes to compose this file and the longer it takes to load it.

More requests = more bloat = longer FBT.[quote]the server can’t possibly know what assets are even going to be called until the HTML requests them [/quote]It DOES know, it finds out after the handshake. It queries the db and the scripts during FBT, in order to then compose the executable page source code. Which the browser then executes - it’s how the BROWSER knows what to look for!

[quote=“Anton_Chigurh, post:25, topic:9482”]

Gnaser is correct. Frontend bloat such as image size or javascript doesn’t affect the TTFB one bit. There is no question about this.

It’s all about the backend processing when it comes to the TTFB. You can’t see that on the webpagetest results because it happens on the server side before the file gets sent to the browser. Whether an image is 5mb or 1mb, or if the page contains 1000s of requests it won’t affect the TTFB. What matters is how that page is put together in the backend code before it gets sent to the browser, which you cannot see on webpagetest.

The decrease in the TTFB you noticed by removing plugins would be related to the decrease in PHP and database calls not the amount of requests.

[quote=“clubberz, post:26, topic:9482”]Gnaser is correct. Frontend bloat such as image size or javascript doesn’t affect the TTFB one bit. There is no question about this.

It’s all about the backend processing when it comes to the TTFB. You can’t see that on the webpagetest results because it happens on the server side before the file gets sent to the browser. Whether an image is 5mb or 1mb, or if the page contains 1000s of requests it won’t affect the TTFB. What matters is how that page is put together in the backend code before it gets sent to the browser, which you cannot see on webpagetest.

The decrease in the TTFB you noticed by removing plugins would be related to the decrease in PHP and database calls not the amount of requests.
[/quote]But, yes you can. I showed how this is done in the posts I linked.

HOW that page source code file is “put together” is from the 100s of queries done during FBT which is reflected in the content of request #1. Reduce the need for so many queries by reducing the number of requests it has to find and compile, reduce the FBT. It’s proven. The requests GENERATE the calls, and the resulting page source code is compiled. Then that is uploaded by the browser, which then executes it.

The browser does not “know” what requests to look for, until the executable file represented in request #1, tells it.

As far as image file sizes go - each and every time I have optimized images for a client, taking out tons of bloat - magically the TTFB drops like a rock. Still no clue why this happens, but I was not at all addressing that.

I was right about CDNs affecting the target TTFB that WPT assigns, and Patrick did a fix for that. I’m right about this as well. The amount of requests after a certain point, DOES increase FBT.

[quote=“Anton_Chigurh, post:27, topic:9482”]
HOW that page source code file is “put together” is from the 100s of queries done during FBT which is reflected in the content of request #1.[/quote]

I was the one explaining this to you, but you’re getting confused as to what I meant.

The ‘100s of queries’ will be in the backend from server-side files such as PHP files which won’t be seen on the frontend. The server won’t process frontend files such as images or css files (there’s no need for it to), and will only see it as text in the HTML file to pass on to the browser. After the browser gets the initial file(typically an HTML file) it then decides which files it needs to display the page and will request them from the server. This would be the first time the static file is actually called, therefore the size of the images or amount of frontend bloat wouldn’t affect the TTFB of the initial request.

It is strange you have noticed this, perhaps if you share the tests when you come across it in the future others can chip in to offer an explanation, as something else would have to be going on.