• UID623
  • Fans4
  • Follows1
  • Posts72

How to optimize website access speed

More Posted time:Dec 14, 2016 11:30 AM

Many webmasters once encountered slow website access. Today we will try to understand and solve this problem.
First, let's take a look at what processes exist between our requesting to access a website from a browser to the webpage showing up.
First, you need to perform the following before the HTTP request:
• Obtain the IP address. After you enter and submit the URL in the browser's address bar, first the browser will try to locate the URL in the DNS local cache table. If the URL is found, it will directly tell the IP address. Otherwise, it will request the gateway DNS to make the query. After the corresponding IP address is found, it is returned to the browser.
• Establish the TCP connection. After getting the IP address, the browser starts to complete the three-way handshake with the requested server to establish the TCP connection.
• Once the connection is ready, the browser sends the HTTP request to the server.
The HTTP request will first get the page file and then it will parse the resource files in the page files,
including the css, js, and images. It then sends the request to get these resource files. In an HTTP 1.1 request,
multiple requests can be concurrent, but the page files must arrive first to inform which resource files to request.
So there are several phases throughout the process. The first phase is the time used for getting the first byte,
that is, the time used from the URL request to the server returns the response for the HTTP request it receives.
This is not limited to the time for DNS and connection establishment. For a dynamic page,
it should include the time until the server returns the page code after its completes implementing the dynamic code.
As a result, computation and database operations will also directly increase the time used for getting the first byte.
While for static files, it is usually fast to get the first byte.
But if the network to the server is not good enough, such as the server is located overseas, it will lead to long latency.
In Alibaba Cloud Cloud Monitor, you can set any HTTP monitoring points as you like to monitor the server response time.
For example, I set two websites on the same server:

Here we can clearly see that for the WordPress which requires calling the database,
the response time is much longer than eitdesign which only requires simple XML reading.
For eitdesign however, the response is almost instant. Here the influence of the physical distance of the server can be manifested.
Because the server is located in Hangzhou, the access from Hangzhou only takes 2ms, but the access from Qingdao takes 23ms.
The response time from the data arriving at the server to it returning can be obtained through the ping command.
Many have used the ping command, but it seems that most of them only use it to check the server connectivity.  
First, let's talk about the principle of ping: Send an ICMP echo request message to the target and report whether the expected ICMP echo response is received.
In theory, the target should return data of the same size as the pinged data, so that we can easily judge the communication state with the server.
So if the response time of the ping command has been steady, but a sudden fluctuation appears, it may be because the bandwidth is used up suddenly.
At this time, we can easily locate the problem with the help of server resource monitoring.

By ping commands, we are constantly refreshing the page. We can see that the time becomes long at a specific moment, meaning the bandwidth is fully occupied at this moment.
The second phase is the time used to get the page files. Before the page file is obtained, there will be no request for any resource files.
Because we don't know which resource files the page has yet. So the time is also crucial.

The third phase is the time used to get the various resource files in the header. The resource files are loaded in the sequence they appear in the HTML pages.
So the resources in the header will be loaded first, including mainly the css and js files, and then the page is rendered.
Pay special attention to the time needed for loading the resources in the header. After all, before the page is rendered, what users see is just a blank page.
The fourth phase is the time used to get the remaining resource files, mainly the images, animations and videos among other files.
They are not that important, after all the page has been displayed, and most users will tolerate the several seconds for loading these files.
In fact, there is also the page rendering time. But since page rendering is concurrent with page loading, and usually not slower than the loading, it can be ignored.
Test tool
To obtain this data intuitively, you can check the page timeline, that is, the waterfall plot.
Currently, the built-in debugging tools of various major browsers all support this feature. Take this website and the Safari browser for example.
See the figure below: First access (In Safari, you can ignore the cache by pressing Shift + Refresh buttons):

Second access:

From the figure we can clearly see that a total of 47 resource files are referenced, and the data totals 2 MB. The first access takes 1.07 seconds in total, and the second access takes 825 ms.
About the first access: The first blue line is the page file, with a total size of 50.89KB. The transmitted size after compression is 10.58KB.
The response time is 342 ms and loading time is 66.1 ms. After this file is parsed, the browser starts to request various resource files.
Here we can see two dotted lines. The blue one represents the DOMContent event triggering time, 635 ms in this case.
It indicates the current browser has completed parsing the document (but other resources, such as images, haven't been fully downloaded).
The red one represents the Load event triggering time, being 1.07 seconds in this case. It indicates all the resources have been loaded.
At the first access, all the resources should be requested. While at the second access, the local cached data can be used to accelerate the resource loading.
So you need to set the timeout duration for static resources with few changes, telling the browser not to re-load this resource during a period of time.
This can speed up the second access by the user, and greatly reduce the time required for the fourth phase.
This timeline is not only available in the local browser, but you can also view it on related testing websites,
such as Alibaba's Alibench, and Google Page Speed and Yahoo YSlow.
There is also a good tool called GTMetrix which make some combinations of Google Page Speed and Yahoo YSlow.
At the same time, these websites will also provide suggestions on improving the websites.
Another tool named 17CE can test the server response time and ping time from different regions at the same time,
which helps to understand the access speeds of users in different regions.
Optimization scheme
Okay. Now we have the basics and tools, we can start targeted optimization. Next I will detail the optimization approaches for various sections:
Phase 1: There are basically no better options to optimize the server response time. If it is a dynamic website,
approaches are dominated by optimization of the algorithm and database, as well as asynchronous data reading using AJAX, which is actually the job of the back end.
We won't go into detail here. But if it takes a website more than two seconds to connect to the server,
basically we can deem that the server has been down. Usually the time needed is controlled within 500 ms.
Maybe this is not a perceivable difference, but it would be better if the time is controlled within 250 ms.
Phase 2: In this phase, the page files are obtained. Page files are usually not big in size, and they are all plain texts.
So the optimization approach is to enable Gzip compression. To achieve this,
for Apache, you should first remove the “#” before LoadModule deflate_module modules/ in httpd.conf,
then restart Apache, and add the following to the .htaccess:
<IfModule mod_deflate.c>
AddOutputFilter DEFLATE html xml php js css text/html text/plain
The effect of Gzip compression is impressive for such incompact plain texts, for example, this homepage of mine is compressed to 10K from 50K.
In addition, you should use external link CSS file and do not place the style sheet directly in the HTML page, so that the CSS file can be cached.

Phase 3: Resource files in the head are mainly css and js files and methods include the following:
• Compression using GZip.
• Use the minified js and css files. The original files are used for modification and the output min versions should be used. Although it is not convenient to read, the size is reduced significantly.
• Merge multiple css and js files to reduce the HTTP request quantity.
• Postpone loading the unnecessary js files to a later stage. For these js files that do not affect the rendering, move them to the fourth phase for loading to shorten the page display time.
• Set a cache time for less updated files and adopt OSS or CDN.
Phase 4: The huge data size occurs in this phase, but currently the bandwidth of most users is not a problem.
The bottleneck happens to the server. Just think if 2 MB of data is required for fully loading a page,
and the server's outbound bandwidth is only 1Mbps, when there is only one user access,
it will require at least 16 seconds to transmit the 2 MB of data, ignoring the latency. This will be intolerable for users.
So if you use a monthly subscription Alibaba Cloud ECS without high bandwidth, you should try to cut down directly-accessed resources on ECS.
The methods are mainly adopting OSS, CDN and GZip compression. The specific optimization means are detail-oriented, in a bid to minimize the data for direct access on the ECS.
However, the case of WordPress is complicated. The js and css files that come with the system or in the system plug-ins cannot be merged and relocated conveniently.

We can only try to optimize them. Take this website of mine for example. After all the images were placed in CDN, there was still around 220KB of data going through the ECS for loading the homepage. In this case if the bandwidth is only 1Mbps, at least two seconds are needed.
Later all the images in the theme as well as the bootstrap and jquery were moved to CDN, and GZip compression was also applied.
After the optimization, only 80KB of data is required through the ECS, and the loading can be completed within one second.
Other notes include:
• Try to minimize the image size on the premise of ensuring the image quality.
• If you want to display a smaller image, do not resize the big image in the page, but use the small image directly.
• Try to use a cookie-less domain name separately for static files.
For websites with high page views, even one byte saved matters. There are also more optimization means available by referring to the page assessment results of Google Page Speed and Yahoo YSlow. But both of these two servers are located overseas so the response time will be much longer. The data can be neglected.
At last, let’s talk about how to set the cache time. For Apache,
first you should remove the “#” before LoadModule expires_module modules/ in httpd.conf, and then restart Apache.
Then add the corresponding code in .htaccess to set the cache time for different file types.
In the following example, the cache time for the image files and js files is one month, and that for the icon file is one year:
<IfModule mod_expires.c>
ExpiresActive OnExpiresByType image/jpg "access plus 1 month"
ExpiresByType image/jpeg "access plus 1 month"
ExpiresByType image/gif "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType text/x-javascript "access plus 1 month"
ExpiresByType application/x-shockwave-flash "access plus 1 month"
ExpiresByType image/x-icon "access plus 1 year"
This article is actually a result of a small fault with Alibaba Cloud server - someday the response time began to stretch so long that the Cloud Monitor issued an alarm. I checked it out and found the response time reached as high as 15 seconds. . .  
I tried to figure out what happened, and started to optimize my website by all means possible. Although the small fault was quickly solved, I benefited from the process to re-study the knowledge on page access acceleration. I started to realize clearly how low 1Mbps is for bandwidth.
Hope everybody finds what they need from this article, and can make their websites just a little quicker.