What makes web sites slow?

Whenever talk comes to the speed of web sites the biggest trick usually advertised is to cut down on the file size of everything (this also leads to endless - and fruitless - discussions about the size of JavaScript libraries. In reality, there are many more factors that play a part in the initial response time of a web page:

• The file size of the HTML document
• The file size of the dependencies in the document (scripts, images, multimedia elements)
• The complexity of the HTML (simpler pages are easier to render for the browser)
• The speed of the connection of the user
• The speed of third party servers as content may be pulled and included from them
• The response time of the DNS servers resolving the domains and pointing you to these other servers
• The responsiveness and speed of the visitors’ computer (how busy is the machine with other tasks - as that impedes on the rendering time of the browser)
• The responsiveness of the server

These are the technical parts of the equation. Then there is also the human factor. Web pages are considered to be not fully loaded until they show up and don’t “jump around” or “have no loading images”.

Things to do to make web sites faster

There are some well-known general best practices you can follow to overcome some of these technical and human factors and ensure a quick response web site:

• Optimize all the HTML and dependencies as much as you can without losing quality (this can include stripping the HTML documents of any comments and superfluous linebreaks, which should be part of the publication process. In order to keep sites maintainable you still need those in the source documents)
• Reduce dependencies by using the least amount of file includes (collate several scripts into one include, use CSS sprite techniques to load all images at once)
• Make sure that you don’t include third-party content from their servers: set up a script that caches RSS feeds locally and use that one instead. The benefit is not only that you don’t have to deal with the DNS server delays but you are also independent of the other server should it go down.
• If possible, define dimensions for images and their container elements. This will ensure that the first rendering of the page will be correct and there won’t be any “jumping around” when the images are loading.
• Include large dependencies such as massive scripts at the end of the document, as this means that the rest of the page gets shown before the browser loads them. Large JavaScript includes in the head of the document mean that the browser waits with rendering until they are loaded.

Best practices vs. special speed requirements

Unfortunately some of these tricks clash with what we consider best practices in web development. Cutting down on the number of included files for example impedes maintainability of the product. In order to make it as easy as possible to maintain the look and feel of a site with different pages (home, articles, archive…) it does make sense to keep the different styles in own includes and only add them to the pages that really use them. You could have one base CSS include and then one for the homepage, one for articles and so on. Read more…

• No Related Post