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.
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.
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.
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.
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).
Figure 1: Slow Time to First Byte
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.
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.
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).
Figure 2: Yahoo! Search Waterfall of Flushing
See Flush HTML early and often for details.
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.
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.
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.
By website optimization on 26 Jun 2013 PM