Website Optimization Tips

Optimization of a modern site consists of many different aspects. All of them are of key importance to your business. To call a site optimized, it must meet the following requirements:

- meet customer requests as quickly as possible
- be properly designed and easy to use
- be able to be used by people with various physical disabilities
- be able to be used regardless of the consumer browser
- be easily found modern search engines

The first paragraph of these aspects, “respond to customer requests as quickly as possible”, is perhaps the most comprehensive and difficult to achieve. This means that if the user wants to download this page, or submit a form, the requested page should be loaded into his browser as soon as possible.

Fast page loading depends on both the optimization of the client HTML / CSS / JavaScript code and the server operation.

The main approach to such optimization is to reduce the network work on the page. This means that requests from the client to the server should be reduced. Reducing requests means we need to reduce the number of images. Image reduction can be achieved by combining in CSS Sprite [1]. Cut scripts and CSS files. For each script and CSS file, the browser makes a call to the server. If the file has a cached version on the client machine, then the cached version will be used if there are no changes to the file on the server. One of the best solutions to reduce the number of scripts and CSS files is to combine them. For ease of maintenance, most programmers prefer to use more than one script and CSS file. To combine them, a program can be used that combines them before they are uploaded to the server. Thus, in the end, it turns out one script and one CSS file that can be requested by the server.

Despite these optimizations, the browser still makes a certain number of HTTP requests to the server. In order to optimize these queries, a complete diagnosis must be made. Diagnosis and proper calculation is the key to optimization. The key to identifying and solving a problem.

Diagnostics of one HTTP request consists of the following components:

DNS time
This is the time during which the DNS system translates the domain to an IP address. Before the client will be connected to the server, you must first translate the domain name to the IP address of the server.

Large sites use more than one domain for their content. Browsers have a limit on the number of open connections. In addition, there is a restriction on simultaneous connections to the same domain [2]. Using more than one domain can increase the speed of loading a site, but this, in turn, increases the number of DNS broadcasts.
When a client wants to translate this domain to IP, the following actions occur:

For an example, we will use example.com

A request is made to a local nameserver. Since the client accesses example.com for the first time, the local server does not know about it. Also, does not know the IP nameserver of a domain. Therefore, he accesses some of the main servers.

A request is made to one of the main servers for accepting TLD nameserver . In the case of example.com, this is the server for .com.

The TLD server is requested for exampleerver nameserver.

Nameserver example.com returns the local nameserver IP address that the domain points to.

The local nameserver gives the client the IP address of the domain.



On subsequent requests to example.com, in general, the above actions will not be performed, but the domain IP address from the cache on the local nameserver-e will be returned.

Caching time depends on the TTL (Time-To-Live) domain described in its configuration. High TTL values, for example 86,400 seconds (24 hours), are better in terms of the fact that the application for updating the record will be made less often. But this also leads to some inconvenience, for example, when you need to quickly change the IP of a domain.

Connect time
After the domain name is translated to the IP address of the server, the client tries to connect to this server. The time it takes to connect is called connection time. This time mainly depends on the speed of the Internet client and server. Packet loss on the route can significantly slow down connection time.

The client does not always open a new TCP session for each request. HTTP / 1.1 supports persistent connections, which means that you can use one session for more than one request. This significantly speeds up the time for receiving results from the server, since there is no Handshaking [3] between the client and the server. All modern browsers support persistent TCP sessions.

Scheme of regular sessions:


HTTP / 1.1, in addition to constant sessions, also adds HTTP Pipelining [4] . Via HTTP Pipelining it is possible to send several requests in one TCP session without waiting for their results.

HTTP Pipelining Scheme.


To use HTTP Pipelining, both the client and server must support it. In modern, popular browsers, only Opera supports it by default. In others, either you must allow it, or it is not supported.

In mobile browsers, everything is different. Both Opera Mobile, Opera Mini, and the Android browser use HTTP Pipelining by default.

Preferably, the server is configured to support Persistent Connections and HTTP Pipelining. This can significantly reduce the loading time of your pages.

Redirection time The
HTTP protocol allows the server to redirect the client to another address. This, in turn, leads to new requests and, consequently, to an increase in the time for obtaining information requested by the client.

It is recommended that you avoid redirected loops whenever possible. This will certainly reduce page loading time. Use redirection only when there is no other solution to the problem.

Time To First Byte (TTFB)
After the client sends HTTP requests to the server, the latter processes it and returns a response. Getting the first TCP packet from the server as an answer - this is getting the first byte.

Higher TTFB value, the slower the processing of resources by the server. For example, when you request a dynamic page with a .php extension. Before a response is received from this page, the PHP interpreter processes it, there is a high likelihood of this page communicating with the database, and only after that returns a response to the client. This means that the TTFB on such a page will be higher than on a simple .html page.

When we know TTFB , we know how long it takes for the server to process this page. Thus, we can undertake various software optimizations on the server. Decreasing TTFB is critical for both server performance and page loading.

Time To Last Byte (TTLB)
After the client receives all the headers and when the last packet arrives, it receives the last byte of the response.

If we know the values ​​of TTLB and TTFB , then we can determine the time it takes for the server to send the entire contents of the client’s resource. TTLB, in contrast to TTFB, is proportional to the size of the resource. However, when the TTLB is too large, the problem is either the server hardware or the Internet speed.

There are many programs that can inspect your site so that you receive the time of each request and each component. For example Firebug, NET tab.

If you want a professional solution that can provide you with round-the-clock statistics of your site, you can use the services of WebSitePulse .
Using the services of WebSitePulse, you can get detailed statistics for your site based on 24-hour monitoring. Detailed graphs of the various loading components of your site will allow you to analyze when and with which deviation your site has problems loading, whether it is connected with a slow connection, or with server loads. These statistics will provide you with a broad overview of the performance of your sites operating in different parts of the world.

1. http://en.wikipedia.org/wiki/Sprite_%28computer_graphics%29
2. http://www.browserscope.org/?category=network
3. Handshaking - http://en.wikipedia.org/wiki / Handshaking
4. HTTP Pipelining - http://en.wikipedia.org/wiki/HTTP_pipelining#Implementation_in_web_servers