Start render optimization takes place before the first content appears to the user, and is critical for good HCI feedback. A fast start render time gives the user visual feedback
that the web server is responsive. Ideally you want a start render time (and useful content
display) of under 1-2 seconds (see Website Optimization Secrets for details). The start render (the time it takes for the first visible changes to appear) is composed of Time to First Byte (TTFB) connect time, server response time, processing objects in the HEAD of your document, and initial page parsing and rendering. Optimizng your start render time is a matter of optimizng each of these delay components.
What is Start Render Time?
The start render time is the moment something first displays on the user’s screen. The web page
goes from a blank white screen and changes. It doesn’t necessarily have to be content; a logo,
or text, it could be a colored background or a search box.
Why is Start Render Time Important
Human-computer interaction (HCI) guidelines recommend a 1-2 second start render time. Giving
the user visual feedback that something is happening behind the screens shows the users that
the site is responsive. Users can plan, anticipate and “attune” to consistent response times
when browsing web pages.
Why Worry About Start Render Times Now?
The average web page has grown inexorably as bandwidth has increased. The average web page
has over 100 objects and is 1200K in size (HTTPArchive.org). Many of these objects are loaded
to slower start render times. In performance audits we’ve seen start renders in the 5-6
second range in some cases, even on cable modem connections! In light of this distressing
situation we find ourselves in, this article shows how to speed up your start render times
with some best practice methods.
Before the web page starts to render, browsers must download and parse the objects on the
HEAD element, and calculate the initial layout before content can show up on the screen.
Optimizing your start render time is mainly a function of server response and optimizng the
efficiency of the elements in the HEAD of your HTML documents. There are a number of best practives
that can be used to speed up start rendering.
Optimize Slow TTFB
The Time To First Byte (TTFB) is the amount of time it takes after the client sends an
HTTP request to receive the first byte of the requested resource from the server. Long TTFB
can mean that the server is experiencing delays processing resources, under heavy load,
or doing complex calculations (see Figure 1).
Typical TTFB (from webpagetest.org) are as follows:
|Static content||Under 100 ms|
For TTFB that are higher than these averages, you need to speed up your server-side latency,
speed back-end number crunching, use a CDN, refactor, or any number of tweaks. See Time To First Byte for details.
Minimize External Resources in the HEAD
your (X)HTML documents the longer it will take to reach the opening body content. Put CSS
files in the HEAD. On Apache use modconcat. See Minimize HTTP Requests, and Object Overhead Graph.
Shard resources across subdomains to optimize parallel downloads
Browsers load objects in parallel to save time. Older browsers load fewer objects at once, newer browsers load more. You can speed up start render times (and load times) by loading more objects in parallel. Browsers limit the number of objects loaded per domain (4/8 etc.). You can fool browsers into loading more objects in parallel by “sharding” objects across subdomains. You can use multiple servers, multiple hostnames per server, or fake it with multiple subdomains that point to the same server. This technique fools browsers into believing objects are being served from different hostnames, thereby allowing more threads per server. For example you can set:
images1.domain.com domain.com images2.domain.com domain.com images3.domain.com domain.com
within your DNS zone record. Now you can reference different objects using different hostnames, even though they are on the same server! For example:
<img src=”images1.domain.com/i/balloon.png” alt=”balloon”>
<img src=”images2.domain.com/i/flag.png” alt=”flag”>
<img src=”images3.domain.com/i/star.png” alt=”star”>
See Optimize Parallel Downloads to Minimize Object Overhead for details.
Flush HTML Early
HTTP 1.1’s chunked encoding allows developers to send chunked content, essentially breaking up a web page into separate components. For some web pages, the backend can generate the HTML slowly, with browsers waiting idly by. For other web pages, the HTML could be generated quickly, but the connection may be slow or congestion may occur. Developers can speed up start render times by flushing a part of the HTML document to the client even before the entire HTML document is ready. Ideally you want to flush just enough initial useful content (say a header that loads quickly) to let the user see or interact with the web page, and leave any heavy database queries till later in the page. Both Yahoo Search and Google use this method of flushing to speed up start render times (see Figure 2).
See Flush HTML early and often for details.
Delay Loading AJAX
Another technique you can use is to send the XHTML page skeleton and fill in placeholders with AJAX calls later. AJAX calls can be expensive time-wise, and you can use empty stub functions and redefine them after the onload event. Alternatively, you can use iframes to load AJAX asynchronously.
GZIP Compress Textual Files
Use HTTP Compression.
Minification is the process of removing unnecessary whitespace, returns, comments and other characters not necessary for functional code. Some minifiers like YUI Compressor go further by abbreviating local variable names with one- or two-character names. Minified code improves performance by downloading faster. Minified code also requires fewer TCP/IP packets, which requires fewer round trips for packets, speeding page display. See Velocity: TCP and the Lower Bound of Web Performance by Steve Souders.
Cache Resources Properly
Web caching stores frequently used objects closer to the client through browser, proxy, or server caches. By storing “fresh” objects closer to your users, you avoid round trips to the origin server, reducing bandwidth consumption, server load, and most importantly, latency. Many pages out on the web have poor caching policies in place, with static resources that have either no expiry headers set (freshness lifetimes), or short or expired expiry dates. This wastes bandwidth on repeat visits and visits to interior pages. Use long expiration dates for static resources, and configure etags properly. See the following tutorial for how to set proper caching policies, set expiration to at least 1 week (some webmasters use years) Localize External Resources for more details.
Optimizing start render times is a matter of streamlining the footprint of the resources that are loaded in the HEAD of your XHTML document, and optimizing the performance of your server. Minimize the number of necessary TCP/IP packets required (minify, GZIP, refactor, etc.) before the opening <body> tag occurs, minimize HTTP requests by combining files, and delay the pain by splitting payloads and delaying AJAX loads. To play nice with TCP slow-start, minimize file size to minimize the necessary packets, and load smaller objects before larger ones.