Nobody likes slow websites. Who does not know them: websites that deform by images that are loaded too slowly, or interesting parts of pages that actually appear in illogical order, and so on.
Web sites are increasingly providing in our daily information needs and are therefore more comprehensive and attractive. Performance is hereby often neglected or dismissed as less interesting.
It is important that the experience of the users of your website is not hampered by bad performance. A user clicks effortlessly away from your website. One wants above all to feel in control. The right design contributes much to this, but a wonderful web page that loads slowly is quickly forgotten.
Bad performance = bad user experience = less prospects
That's why it's important to always monitor the performance of a website. When optimizing websites, there are two guidelines we can hold on to:
- HTTP requests
HTTP requests are requests to the server in which a page or image is requested. Understandably, questions or connections to the server cost time. We would like to minimize such requests. What can we do minimize this number of HTTP requests?- Caching
When we visit a site, the webpage may be cached. For the user this means that script files, style sheets, images and other media files are stored on the hard disk for reuse. If we are again on that page later on, the items will not need to be downloaded again, because they are already in the cache (on the harddisk). This can greatly increase performance.
There are two ways to find out if visitors use caching.
First, we check the server log for the number of per page requests per user and hold that number against the number of image requests per page. Less image requests means more image caching.
In addition, several browser add-ons are available, with which we can take the role of user and see whenever a HTTP request is sent. "Live HTTP headers" for Mozilla Firefox is a popular add-on for this. - CSS Sprites
To reduce the number of used images and thereby to reduce HTTP requests, use can be made of so-called CSS Sprites. This would actually say: combine commonly used images (preferably relatively small, such as icons) to one or more images using Photoshop for example and note the pixel coordinates of the sub-images within the big picture that we want to use.
Next, we will always use the same url to this file when we set the background-image with CSS or JavaScript- Code: Select all
div {
width: 100px;
background-image: url(‘name.jpg’);
}
- Code: Select all
#header {
width: 100px;
background-image: url(‘name.jpg’);
}
note: if a path is used, it should always be relative. Otherwise, a reference to unsafe directories can be shown in the source code. For example "c: \ windows \ secret_files \ name.jpg".
Only the background-position now needs to be different per image:- Code: Select all
div {
background-position: 0px, 0px;
}
- Code: Select all
#header {
background-position: 200px, 0px;
}
In the result we will see that both elements now have a seemingly different background picture. At the #header element is the image is 200 pixels to the right. - iFrames
iFrames are often used when we want to use commercials that are on a different domain, and load them on our page. However, we must try to limit the use of iFrames, because also each iFrame takes up a HTTP request.
- Caching
- Tuning scripts and styles
Loading a script or stylesheet takes a HTTP request. We try to minimize such requests. In addition, the location of your scripts and / or styles in the code are also important for good performance.
We can choose to primarily use external scripts and style sheets and to lean on the use of caching. As a result, there are few HTTP requests required if the page is in the cache. Another possibility is to make use of inline scripts or style sheets, which can result in a reduction of in the number of requests, but on the other hand can also lead to an increase in the file size (on an empty cache).
In practice, the web site is a combination of both directions. It is often a matter of trial and error which strategy goes for which parts of your website.
A typically easy performance gain, is the merging of scripts or styles to less files. Less files = less HTTP requests. A disadvantage is that this comes at the expense of the manageability of your website.
In addition to the combination of scripts, the adjustment of the location of scripts within the page is also an important factor when tuning. Scripts are known to block the download of other elements on your webpage. This requires users to wait long(er) than necessary. The location of an inline script or reference to an external file is inherent to when the script is loaded. The lower on the page, the later it will be loaded.
For scripts that dynamically change the page, it is not advised to move them down on a page, because a 'document.write' will mess up the page. Another solution will have to be thought up for these kind of scripts.
There are alternatives available: deferring scripts. This is done with the 'defer' attribute, but since HTML5 also with the 'async' attribute.
The syntax is as follows:- Code: Select all
<DEFER SCRIPT src=”functies.js”></SCRIPT>
and:- Code: Select all
<ASYNC SCRIPT src=”functies.js” ></SCRIPT>
When using DEFER, the script will be executed after the whole page is parsed. However, the script downloading will commence immediatly after opening the page.
When we use ASYNC, the script will also downloaded immediatly (in parallel), but is immediately executed after it is downloaded. This can be a problem if we have multiple scripts with the ASYNC attribute and we want them to be executed in a predetermined sequence.
Summary
As we have seen, when managing websites it is of great importance to monitor their performance. In particular, the number of HTTP requests that are being used. For this we can mainly focus on caching and CSS sprites. It is also important besides the HTTP requests, to optimize the execution of scripts and styles. This can be done by combining scripts or styles, and managing the execution of scripts by using ASYNC, DEFER, or simply moving code.
--By Stinow
