Time to first byte

Initial connection and time to first byte seem to be important metrics on website performance when we take a look at the charts that the tool WebPageTest is generating. Web browsers do their best to fetch resources in parallel and we can further support them by dividing the resources over several domains. This allows us to achieve better parallelism, but requires some additional time for DNS resolving per domain. It may be a better idea to use subdomains instead of domains as this could give us more predictable results. That we can load resources in parallel doesn’t mean that the process will be problem-free, especially when we consider that temporary network congestion, high server load and other factors may affect the feel of a website. Sometimes the browser may change its initial strategy as new information becomes available. But we can see that the loading pattern is repeatable. If we have 50 HTTP requests and 4 of them can be loaded in parallel, the model will show around 13 segments under ideal circumstances.

Once the DNS is resolved, time for initial connection and time to first byte become important. Establishing the initial connection to a resource can sometimes take more time than fetching the resource itself. And even when we are already connected, we may still need time to access the resource in binary mode or acquire a handle on it. We can see that these two times are available for almost every resource we load and sometimes they can be very similar for resources in the same segment. This means that any savings we are able to extract from reducing these times will be reflected in all segments. The more segments, the bigger the savings (at least in theory). At some point we need to decide whether the parallelism factor (vertical) is more important than the segment factor (horizontal), but so far we have seen that the first is always catching up. Some of the most visited websites have recognized this and have taken measures to decrease these two times as much as possible. As a result, their segments are quite short and resources appear almost burst-like. Fully eliminating the time for initial connection and the time to first byte may not be feasible.

Content download becomes critical if we need to transfer lots of data. We can hardly do this faster than the browser is able to display the data. If we aren’t using additional threads for this purpose, we may block the main one. Instead of sending too much data, it may be better to prioritize it in chunks and decide whether a socket connection could make more sense if we want to minimize the headers sent. In general, content download will have a smaller impact on the overall loading time if we care to send only the data that is immediately needed. It is relatively fast, backed up by modern CPUs. Content download is the last time in a segment, so it may be harder for the browser to align and do it in parallel. If we try to minimize the segment time this way, we may lose some milliseconds for synchronization.

Many times the segments will overlap, which allows resources to start loading before others have finished. This doesn’t change the meaning of what was said so far. It just becomes harder to distinguish the borderline between individual segments. By trying to do it, we can gain a better understanding of how and when the browser decides to load resources of particular type and how the sequence of loading events affects the loading itself. Because reloading the same site will give us different results every time, we may be able to get a feel of what the browser does and use this to pack the time segments in a way that accounts for surprises, but still leads to relatively consistent results.

Of course, web design is much more than simply speed, determined by network characteristics and less by computational efficiency. It is meant to enable, intensify, catalyze and empower. To serve. Anything else in the design is really a reflection of this, which is why design choices need to follow more meaningful directions. It’s probably better to move slowly in the right direction than to rush in the wrong one.

bit.ly/1ilySqU