1 - Minimize HTTP-requests:
-In the HTTP request environment
On accessing a page by a user most of the page load time gets spent on uploading a variety of page components: HTML structure of the page, JS scripts, CSS, images, flash, etc.
Given the number of components is being reduced, HTTP-requests quantity gets decreased several-fold, thus the former will strongly factor into speeding up the page load time.
Combine Javascript into one file, and CSS files into one CSS.
The presented calculation is quite simple: 10 JS-files = 10 HTTP , 1 JS-file = 1 request - on the assumtion that the majority of browsers postpone uploading the page until the moment each JS file has been loaded and processed.
Using СSS-sprites helps decrease the number of instances of the background image retrieval.
2 - Using compression:
Gzip seems to be a most popular method of compression.
Normally, compression is applied to HTML, CSS, JS. As for Gzip it is less appropriate, though, to apply it to images and PDF-files, as the latter have yet been packed and it hurts by trying up to pack them again with Gzip as it may expand the file too much. Drupal makes use of CSS Gzip and Javascript Aggregator modules.
3 - Minimizing JavaScript and CSS:
In fact, removing unnecessary characters from the code seems to be one of the practices that reduce its size and thus improve page load time. To minify a code all comments are being removed, as well as unneeded white space characters (space, newline, and tab). In the case of JavaScript, this improves response time performance because the size of the downloaded file has been reduced. JSMin and YUI Compressor are two most popular tools for resizing JavaScript code. The YUI compressor can minify CSS, too. Javascript Aggregator may be used in Drupal, too. CSS minifying is launched authomatically in Drupal 7 when css compression gets turned on.
4 - Improving the way styles and scripts are included into a document:
Metatags and <title> should go first in <head> tag of page to be followed by stylesheets. It explains why many browsers, Internet Explorer included, block rendering routine to avoid redrawing the elements after their styles have changed. The user is being stuck viewing a blank white page until styles have been downloaded.
Write JS scripts after all <head> elements. The problem with the scripts is that they block parallel downloads. The HTTP/1.1 specification suggests that browsers can download no more that two components in parallel per hostname. While the script is being downloaded, the browser won't start any other downloads, even on different hostnames. That's the reason for moving as many scripts as possible to the bottom of the page.
5 - Avoiding CSS Expressions:
CSS expressions are a powerful and risky way of setting CSS properties dinamically, and they are supported in Internet Explorer versions 5 through 7. The problem with expressions is that they are evaluated more frequently than most people would expect. Not only they are evaluated when the page is rendered and resized, but also when the page is scrolled and even when the user moves the mouse across the page. Adding a counter to the CSS expression allows keeping track of when and how often CSS expression is evaluated. Moving the mouse around the page can easily generate more than 10,000 evaluations, hence if you still need to use CSS expression, remember that it affects productivity of your page.
The problem with AlphaImageLoader filter (fixing problem with semitransparent PNG in IE version <7) is that it blocks rendering and "freezes" browser's window when the image is being downloaded. This also increases memory consumption affecting each element (and not the image only) thus contributing to the problem. Staying away from AlphaImageLoader and replacing it with PNG8 instead seems to be a better option in keeping aflote productivity in IE. In the cases when AlphaImageLoader filter is the only option, the hack with underline _filter can well be used, so as to keep our IE7+ users happy (if you have separate file for all IE) or else, you can use JavaScript, as a better option.
6 - Using external JavaScript and CSS:
Using external files speeds up page download times as JavaScript and CSS files are being cached by the browser. JavaScript and CSS that are inlined in HTML documents get downloaded every time the HTML document is accessed. The only exception where inlining is preferable is with home pages that have a few (perheps only one) page views per session, then you may find that inlining JavaScript and CSS may result in faster end-user response times.
7 - Removing duplicate scripts:
It also hurts by including JavaScript file twice in one page. This isn't as unusual as one might think. Yahoo! reports that in two out of ten top U.S. sites duplicated script was found. In Internet Explorer, if an external script is included twice and is not cacheable, it generates two HTTP requests during page loading. Even if the script is cacheable, extra HTTP requests occur when the user reloads the page.
8 - Post-loading components:
JavaScript is an ideal option for splitting before and after the onload event. For example, if you have JavaScript code and libraries that perform drag and drop and animations, those can wait, because dragging elements on the page comes after the initial rendering. Other places to look for candidates for post-loading include hidden content (content that appears after a user action) and images below to fold. Post-loading appears to be the best choice in case it's used with other web development best practices. In this case, the idea of progressive enhancement tells us that JavaScript, when supported, can improve the usability but you have to make sure the pages work even without JavaScript. So after you've made sure the page works fine, you can enhance it with some post-loaded scripts that give you more bells and whistles such as drag and drop and animations.
9 - Preloading components:
By preloading components you can take advantage of the time the browser is idle and request components like images, styles and scripts you'll need in future. This way the next page will load much faster, as most of the components are already in the cache in user's browser.
There are actually several types of preloading:
- Unconditional preload - as soon as onload fires, you go ahead and fetch some extra components. Check google.com for an example of how a sprite image is requested onload. This sprite image is not needed on the google.com homepage, but it is needed on the consecutive search result page.
- Conditional preload - based on a user action you make an educated guess where the user is headed next and preload accordingly.
- Anticipated preload - preload in advance before launching a redesign. It often happens after a redesign that you hear: "The new site is cool, but it's slower than before". Part of the problem could be that the users were visiting your old site with a full cache, but the new one is always an empty cache experience. You can mitigate this side effect by preloading some components before you even launched the redesign. Your old site can use the time the browser is idle and request images and scripts that will be used by the new site.
10 - Reducing the number of DOM elements:
DOM elements in excess might be a sign that there is something that should be improved with the markup of the page without necessarily removing content. Are you using nested tables for layout purposes? Are you throwing in more <div>s only to fix layout issues? Maybe there's a better and more semantically correct way to do your markup. For instance, use <div> only when it has semantic value not only because it makes a newline.
It's easy to test the number of DOM elements, just type Chrome Devtools console:
document.getElementsByTagName ('*'). lenght
And how many DOM elements are too many? To find out, just check other similar pages that have good markup.
11 - Minimizing the number of iframes:
Iframe allows an HTML document to be inserted in the parent document. It's important to understand how iframes work so they can be used effectively.
<iframe> pros:
- Helps with slow third-party content like banners
- Security sandbox
- Download scripts in parallel
<iframe> cons:
- Costly even if blank
- Blocks page onload
- Non-semantic
12 - Image optimization
Use GIF-file for very small and simple graphics instance (for example less than 10x10 pixels or color palette of less than 3 colors) and for images that contain animation. Try converting GIFs to PNGs and see if there is a saving. More often than not, there is. Developers often hesitate to use PNGs due to the limited support in browsers, but this is now a thing of the past. The only real problem is alpha-transparency in true color PNGs, but then again, GIFs are not true color and don't support variable transparency either. So anything a GIF can do, a palette PNG (PNG8) can do, too (except for animations).
Use JPGs for all images of photographic style.
Don't use BMP or TIFF.
Use tool of PNG optimization for all your PNGs and JPEG optimizer.
You should clearly see the benefit of any file that can be reduced by 25 bytes or more (if less, this will not increase productivity noticeably).
Arrange the images in the sprite horizontally as opposed to vertically usually results in a smaller file size.
Combining similar colors in a sprite helps you keep the color count low, ideally under 256 colors so as to fit in a PNG8.
Don't leave big gaps between the images in a sprite. This doesn't affect the file size as much but requires less memory for the use agent to decompress the image into a pixel map. 100x100 image is 10 thousand pixels, where 1000x1000 is 1 million pixels.
Don't use a bigger image than you need, i.e. don't reset the size in HTML. If you need <img width="100" height="100" src="yolka.png" alt="Yolka" />, then your image should be 100x100px rather than a scaled 500x500px image using width & height attributes.
In this article is written the basis of How to Increase Page Load Speed.