Website Developer Best Practices for Speed Loading
An exceptional performance team of website developers have recently identified a number of methods for making web pages load quickly. We've reiterated a couple of their recommended practices in this article for web developers trying to understand speed loading techniques.
Get a grip on the top and bottom
The problem with putting stylesheets near the bottom of a document is that it slows progressive rendering in many browsers. Why? The browser block rendering to avoid having to re-draw elements if the styles change, you know that little shift across the page to apply the styles? So, the user is stuck looking at a blank page and all web developers know what bored users do (they abandon the page).
The problem with putting scripts at the top of the page is that they block parallel downloads. The HTTP/1.1 specs request that browsers download no more than two components at the same time per host. If you serve your images say, from multiple hosts, you can get more than two downloads to occur in parallel. While a script is downloading, however, the browser won't start other downloads – even if they are on different hosts.
So, what's a website developer to do about the top and bottom of their pages if they care about speedy loading?
Put the stylesheets at the top and the scripts at the bottom.
The HTML spec clearly states that stylesheets are to be included in the HEAD tag of any page and the alternatives – a blank white screen or a flash of unstyled content that later shifts dramatically are worth the risk if you want to retain your visitor. The optimal solution is to follow the spec and load your stylesheets in the document's HEAD tag.
Use a content delivery network
Here's a performance rule many web developers don't know: 80-90% of user response time is spent downloading the components of a web page. That means the images, styles, scripts, flash, etc. The first inclination by many website developers is to redesign the web application to work in a distributed architecture, which might include such daunting tasks as synchronizing session state and replicating database transactions across server locations.
Rather than starting with the task of redesigning your application architecture – a daunting and difficult task at best – start with dispersing your static content instead. This achieves a better response time quickly and it's far easier given the availability of content delivery networks, which is a collection of web servers distributed across multiple locations and used to deliver content.
The server is automatically selected based on a measure of network proximity to the user. This means the server with the fewest network hops or the one with the quickest response time is selected.
Many large companies own their own CDN, but that is a cost prohibitive move for many small companies or private websites. It's more cost-effective to use a CDN service provider. Plus, switching to a CDN is a relatively quick and easy change in code for a website developer and it will dramatically improve the speed of your website.