Server developers should be aware of the connection’s current cwnd and should take this into account when deciding how much data to push. On Linux, the current cwnd can be obtained through getsockopt(fd, SOL_TCP, TCP_INFO), which returns a tcp_info struct that contains the send congestion window size (also see this article). The default initial cwnd can be changed with the global initcwnd setting (see this article). Note that Linux lowers cwnd and reverts to slow-start if keep-alives are enabled and the TCP connection has become idle. This means even “warm” connections may behave like cold connections. This behavior can be disabled by setting tcp_slow_start_after_idle=0 (see the tcp manpage). Server developers should also be aware that the kernel-reported cwnd may be inaccurate in two respects. First, the true cwnd may be artificially limited by the client’s receive window. In Linux, the effective cwnd is actually the minimum of tcpi_snd_cwnd and tcpi_rcv_space (in the tcp_info struct). Second, cwnd may over-estimate the true BDP due to bufferbloat. We have more to say about bufferbloat in the next section, where we discuss rule #2. Web developers should be aware of typical BDP sizes and how those sizes compare to the resources they want to push. Below is a table estimating BDP for a variety of connection types: Connection Type RTT (ms) Bandwidth (kbps) BDP 2G (as defined above) 1420 113 20 KB 3G (as defined above) 209 1360 35 KB 4G LTE (sprint) 150 4500 85 KB 4G LTE (verizon) 150 8500 160 KB 25 Mbps cable 50 25000 156 KB 1 Mbps satellite 638 1000 80 KB A network sees the largest improvement from push if it has high RTT (maximizing idle time to remove) and high bandwidth (maximizing data pushed during idle times). Unfortunately, such networks don’t really exist. The closest is probably satellite internet, which is becoming increasingly rare. The httparchive has stats for a large corpus of web pages. Suppose we served all of these web pages using server push, where a set of “critical” resources are pushed along with each HTML document. Based on stats from httparchive and our data above, we can make a few tentative observations: We expect no improvement from push on cold 2G connections when the HTML document is larger than 5KB. This covers 80% of HTML documents. The situation is better for warm 2G connections, where we expect small improvements for HTML documents up to 20KB. This covers 85% of HTML documents. We expect more relative improvement for faster connections than for slow connections, since faster connections generally have a higher BDP. It is unfortunate that this trend is not reversed. Rule #2: Push Resources in the Right Order Web pages are evaluated in a well-defined order. For example, synchronous scripts are executed sequentially in the order they appear in the HTML file. When a server decides to push one or more resources, it must schedule those resources on the wire in some order. Sending resources in the wrong order will delay client-side evaluation, which can cause slower page loads for a number of reasons, but most importantly: Rendering is delayed if a non-render-blocking resource is sent on the wire before a render-blocking resource. Evaluation of one resource may reveal the need to fetch another resource, such as when a synchronous script injects a reference to another script via document.write. Delay of the first script delays the request for the second script. Note that it may not be possible to push the second script since the URL may be determined dynamically. To demonstrate this effect, we load the following web page: ... 10 KB of junk … The first script (1.js) loads another script (2.js) via a document.write call at the end of the script. The other scripts (3.js, 4.js) are no-ops. The first script (1.js) is 5KB. All other files are 10KB. We experimented with different push strategies to measure how push order affects load time. Using a 2G connection, there is 10KB left in the BDP after sending the HTML file. This means we expect a performance improvement when we push a single JS file. However, when we push multiple JS files, the expected improvement depends on the files we choose to push and the order we push them in.