Geekly Articles each Day
📜 ⬆️ ⬇️

Static sites: customization and optimization

static sites

We continue the cycle of publications about static sites based on our cloud storage (see previous publications here and here ). Today we will discuss in detail the issues of their fine-tuning and optimization.

The main criterion for the excellent work of the site from the user's point of view is, of course, the download speed of the components. If the site is loaded for some reason for too long, it inevitably leads to the loss of visitors who are tired of waiting. To make the site fast and convenient, you need to do some work on its optimization.
')
Below we will give a number of recommendations with which you can increase the speed of a static site hosted in our repository.

Tip 1. Use the power of CDN


We have already written about connecting to our CDN cloud storage from Akamai. CDN stores all static content (images, text files, JS, CSS, and so on) on caching servers scattered around the world (see the map here ).

When accessing a web page or its resources, the request will be processed by a cache server geographically closest to the client. The use of CDN helps to increase the download speed of the site for both stationary and mobile devices.

By default, all data is cached in the CDN for 24 hours. Recently, a new function has been added to the repository, with which you can clear the CDN cache at any time:

CDN cache

To do this, simply go to the tab shown in the figure and enter in the form of the address of the pages whose cache you want to clear. The cache will not be cleared immediately, but approximately 15 minutes after the form is submitted.

Tip 2. Don't forget about caching settings.


Any web page includes many different elements: images, scripts, style files, and so on. The user visiting the page for the first time receives all these elements by performing a series of HTTP requests. To avoid reloading a large number of files, caching is used.

The caching model used in the HTTP protocol is based on the so-called validators - special headers used by the client to make sure that the cached document is still relevant. Thanks to the validators, the client can check the status of the document without sending the entire cached copy to the server. In turn, the server sends a document in the response only if the validator received by it indicates an obsolete copy in the client’s cache.

Validators are divided into strong and weak. Strong validators appeared in HTTP / 1.1. They are called so because they change whenever a file changes. These include the so-called ETags (entity tags). ETag is the content ID of the document; it changes if at least one bit changes in the document. As an identifier, for example, MD5-sum of the document content can be used. When a client requests a document from the server, the ETag value is transmitted in the response, for example:

 HTTP / 1.1 200 OK
 Server: Selectel_Storage / 1.0
 Accept-Ranges: bytes
 Last-Modified: Mon, Aug 18, 2014 12:25:38 GMT
 X-Timestamp: 1408364738.80296
 Content-Type: image / jpeg
 Content-Length: 458073
 Access-Control-Allow-Origin: *
 Access-Control-Expose-Headers: Last-Modified, ETag, X-Timestamp
 ETag: "ebef3343a7b152ea7302eef75bea46c3"
 Date: Wed, 20 Aug 2014 11:52:48 GMT

When you re-request the same document, the saved value of the validator is already transmitted in the If-None-Match header:

 GET / HTTP / 1.1
 Host: example.org
 If-None-Match: "ebef3343a7b152ea7302eef75bea46c3"

If the document has not been modified, then the server will return only the headers and the 304 Not Modified code in the response. Otherwise, the server will return the code 200 and transmit a new version of the document, as well as a new ETag value for it.

In our repository and ETag is generated immediately after downloading the file. It is an MD5 hash of content. If the content changes, then the ETag changes.

Weak validators are called, which do not necessarily change with every file change.

An example of a weak validator is the Last-Modified header. The value of this header is the date the file was last modified. In our storage, it is installed automatically. If you specify a date in the If-Modified-Since header not earlier than the one currently contained in the Last-Modified header, then the response will also be 304 Not Modified.

Strong validators can be used in any context. Weak validators are used in a context that does not depend on the exact contents of the file.

For example, validators of both types can be used in GET requests with a condition (If Modified Since or If None Match). However, when downloading files in parts, only strong validators can be used - otherwise the client will receive the file in a non-consistent form.

Tip 3. Notice the Cache-Control header.


To set the storage time in the browser cache for a copy of the file whose original is in the storage, use the Cache-Control header with the max-age directive. Thanks to this header, you can significantly increase the speed of loading the site - if the file is cached, the browser will instantly display the content from the cache, without making any request to the site.
The file storage time is indicated in seconds:

 Cache-Control: max-age = 7200

In the example above, it is 7200 seconds (2 hours). Usually, CSS, JS and graphic files are cached this way. It is desirable to cache them forever, and when changing the content, change the links to them in HTML. RFC 2616 for such files is recommended to specify the caching time not exceeding 1 year:

 Cache-Control: max-age = 31536000

If you want a specific file not to be cached, but always to be “fresh”, the following value is set for the Cache-Control header:

 Cache-Control: no-cache

It indicates that the item should not be cached at all and that the client should request it each time the storage is accessed (the file loading time will increase in this case, since you will have to download the file body).

Another way you can always get a file in the current version is to add a checksum to the file name.

If the content of the file changes by at least one bit, then the checksum will also change. If there were no changes, the browser uses the file from the cache. When a file changes, the link to it will change, and a new version will be downloaded.

You can get a checksum using either standard md5sum or sha1sum utilities, or using special utilities.

You can also add an arbitrary set of characters to the links to the files — for example, a timestamp (http://example.com/script.js?timestamp_here),- and update the links every time the site is added. When using this method, however, there is no guarantee that the browser will not make unnecessary requests: even for files whose contents have not been changed, there will be another link (the caching key is the entire link along with the query parameters). download them again.

For HTML pages, it is preferable to set the Cache-Control header to no-cache. If you need to urgently change something on the page, and the client has already cached this page (modern browsers do this by default), then the client may not see the changes at all.

This is especially important when using a CDN: By default, the Akamai DN caches files without corresponding headers for 24 hours. You can, of course, clear the cache (see above), but you have to wait at least 15 minutes after sending the corresponding request. Setting the same value to no-cache will help avoid potential problems - the page will always be loaded in its current form. In this case, browsers will still use If-None-Match headers (or If-Modified-Since), and a page that has not been changed will not load again.

In some cases, it is better to specify the time for caching HTML pages based on the frequency of changes. For example, if the page with news on the site is updated every hour, then for max-age you can set the value to 3600 (1 hour).

The value of the Cache-Control header (as well as other HTTP headers) in our repository can be set via the web interface:

static site

Through the web interface, header values ​​are set only for the container as a whole. Header values ​​for individual files can only be set via the API or using third-party clients.

Instead of Cache-Control, you can use the Expires header. Its value indicates the date in the format of RFC 1123 date format, after which the file ceases to be relevant (for example: Tue, 31 Jan 2012 15:02:53 GMT). Until this date, the browser will not make requests to the site, but will receive the file from the cache. After this date, the file will be downloaded again.

Tip 4. Use gzip compression


With the help of compression, you can significantly speed up the site loading. Starting with HTTP / 1.1, clients report supported compression methods in the Accept-Encoding header:

 Accept-Encoding: gzip, deflate

In the server's response, information about the compression method used is transmitted in the Content-Encoding header:

 Content-Encoding: gzip

One of the most popular and most commonly used methods today is, of course, gzip. With it, you can significantly reduce the load time. Gzip especially effectively works with text files: HTML, CSS, JS. Due to compression, the size of text files (and, accordingly, the volume of transmitted traffic) is reduced by an average of 5-10 times. This allows you to significantly increase the speed of loading the page, which is especially important for mobile clients with slow connections.

There is no point in using gzip for graphic files: compression does not help to significantly reduce their size, and often even increases it.

In Akamai CDN, gzip is used for most text files by default.

Tip 5. Minify JS and CSS


Minification is the removal of unnecessary / optional characters from a file in order to reduce its size and reduce loading time. Due to this, the file size is reduced on average by 1.5-3 times. Today, the practice of minifying not only JS and CSS, but also other types of files (HTML, graphic files, etc.) is becoming widespread.

For minification, special tools are used, in particular:


Using minification, you can not only remove insignificant spaces and line breaks (they are optional in CSS and JS), but also perform more complex operations. For example, in the JS function of the form:

 function summ (first_param, second_param) {
   return (first_param + second_param);
 }

You can turn it into function s (a, b) {return (a + b)} and then everywhere in the code you can use s instead of summ, while retaining the logic of its operation. You can see how the JavaScript minification procedure works at http://lisperator.net/uglifyjs/ in the Open Demo section.

Tip 6. Use concatenation


Modern browsers make an average of 6 parallel domain requests. If the site contains many small files, its download time may be delayed - this is especially noticeable with a slow or unstable connection.

Here concatenation can help - combining several files of the same type (for example, JS or CSS) into one. It allows you to reduce the number of requests and thereby increase the speed of loading pages.

Concatenation can also be used to speed up the loading of images. It can be done in two ways: using data embedding in a URL and using sprites.

The implementation of the data is carried out using a special type of URL - data: URI. The Universal Resource Identifator URI can be used both in the src attribute of the img tag and in the background image URL in CSS.

There are online tools for converting images into data: URI (see, for example, here and here ).

Sprite is a collection of images, combined into one image. For the formation of sites using various software tools. With CSS, you can access the desired part of a large image and place it in the right place on the site.

Sprites help to increase download speed, but it should be noted that working with them is often fraught with difficulties. To make even a small change to the sprite, you will need to make related changes in the CSS.

In modern tools to build projects on JS ( Brunch , Grunt , Gulp, and others). minification and concatenation procedures can be automated. In order to perform all the necessary file operations (including the final deploy on the server) using a single command, it is enough to create a small configuration file that describes the order and properties of the assembly.

For those who want to learn more


Features of the development and configuration of static sites - an extensive topic, and in future publications, we will continue it. For those who want to explore this topic deeper, both in theory and in practice, here are some useful links:



All questions and comments will be answered in the comments. For our part, we promise to talk about current trends in the development of static sites in one of the upcoming publications.

Readers who for one reason or another can not leave comments here are invited to our blog .

Source: https://habr.com/ru/post/237159/

More articles:


All Articles