How to speed up the loading site
Nikolay Lavlinsky, Technical Director of Method Lab , specifically for Netology, talked about how to speed up the site and not lose anything. The article participates in a blog contest .
Everyone knows that a slow site is bad. Because of the braking site, serious problems arise when solving everyday tasks. Sometimes it's just annoying. Often the braking of a site is a breakdown, a denial of service — people do not wait for the download and leave. This is true for cases of radical braking of the site, for example, when the start of page rendering begins 8–10 seconds after the click.
')
Even with a relatively favorable situation with the site (with fast downloads on the wired Internet and a modern computer), delays in the download can lead to loss of audience and a decrease in conversion. For example, Amazon conducted an experiment in which it found that every 100 ms (0.1 s) delays lead to a decrease in sales of 1%.
But more than half of Internet users today use mobile devices to access sites. So they can use slow access channels and processors to download the site.
The third reason for the importance of the site speed question is technical. As a rule, slow websites consume an increased amount of hosting resources, which leads to additional costs. Server-side brakes reduce the ability to relive the peak load on the site without any problems.
Therefore, the speed of the site should be dealt with both from a technical and economic point of view. In this article we will focus on the technical side of speeding up sites.
The speed of the site concerns two sides: client and server. Today, each of these parts is equivalent for the final result. But each with its own characteristics.
To understand what forms the load time of the page, we analyze this process into stages. As a result, we can understand where the server and client optimization capabilities are located.
The full process of loading the site (first visit) is as follows:
In this process, some positions occur in parallel, some may change places, but the essence remains the same.
Server optimization deals with stages one through four, inclusive. Stages 5 through 12 are client optimization. The time spent on each of these stages is individual for each site, so you need to get site metrics and identify the main source of problems. And here we come to the question of how to get and interpret these metrics.
The main question: what should be measured? There are many metrics on the speed of sites, but there are not so many main ones.
First, this time to the first byte (TTFB - time to first byte) is the time from the start of the download process to the receipt of the first portion of data from the server. This is the main metric for server optimization.
Secondly, this is the beginning of the page rendering (start render, first paint). The metric shows the time until the end of the “white screen” period in the browser when the page begins to be drawn.
Thirdly, it is loading the main elements of the page (load time). This includes loading and interpreting all resources for working with the page, after this mark the page loading indicator stops spinning.
Fourthly, this is a full page load: the time until the end of the main activity of the browser, all main and deferred resources are loaded.
These basic metrics are measured in seconds. It is also useful to have an estimate of the traffic volume for the third and fourth metrics. Traffic needs to be known to evaluate the effect of connection speed on load time.
Now you need to understand how to test the speed. There are many services and tools for assessing the metrics of the speed of loading sites, each of which is better for its task.
One of the most powerful tools is the developer panel in the browser. The most advanced functionality of the panel in Chrome. On the Network tab, you can get metrics on the load time of all elements, including the HTML document itself. When you hover over an item, you can find out how much time is spent on each stage of obtaining a resource. To evaluate the full picture of the page loading process, you can use the Performance tab, which gives full details up to the decoding time of pictures.
If you need to estimate the speed of the site without full details, it is useful to start the site audit (Audits tab), it will be performed using the Lighthouse plugin. In the report, we get a speed estimate for mobile devices (both integral in points, and according to our main metrics) and several other reports.
Among web services, the WebPagetest system has become the professional standard. This service loads the site in real browsers with a given type of connection and generates a detailed report on all stages and metrics.
For a quick assessment of client optimization, you can use the Google PageSpeed ​​Insights service, but you need to remember that it does not include most of the most important metrics on load time. Finally, it is useful to analyze the site load time for real users. For this there are special reports in the Yandex.Metricka and Google Analytics web analytics systems.
Landmarks for site loading times are as follows: the beginning of rendering is about 1 second, the page loading is within 3-5 seconds. Within this framework, users will not complain about the speed of the site and the load time will not limit the effectiveness of the site. These figures should be reached precisely from real users, even in difficult conditions of mobile connection and outdated devices.
We turn to the very acceleration of the site. Optimization of the server part is the most understandable and obvious measure for website developers. First, the server part is fairly easily monitored and controlled on the side of system administrators. Secondly, with serious problems with the response time of the server, the slowdown is noticeable to everyone, regardless of the connection speed or device.
While the causes of server side braking can be very diverse, there are typical places to look at.
This is the reason for the number one slowdown for small sites. For the current site load, there is simply not enough hosting resources (usually, this is the CPU and the speed of the disk system). If you can quickly increase these resources, it is worth a try. In some cases, the problem will be solved. If the cost of additional resources becomes higher than the cost of work on optimization, it is necessary to proceed to the following methods.
Here we turn to solving the source of the problem: low speed of the program code. Often most of the time a web application spends on queries to the database. This is logical, because the task of a web application is reduced to collecting data and transforming them according to a specific pattern.
The solution to the problem of slow responses from the database is usually divided into two stages: tuning the DBMS and optimizing queries and data schemas. Tuning a DBMS (for example, MySQL) can give acceleration several times, if the tuning has not been done before. Subtle tuning can give an effect within ten percent.
Optimizing queries and data schemas is a radical way to accelerate. Due to this optimization, it is possible to obtain acceleration by several orders of magnitude. If a change in the structure of the database can occur without intrusion into the program code of the site, then query optimization will require such intervention.
To identify slow queries, you need to collect statistics on the load on the database for a fairly long period of time. Further analysis of the log and the identification of candidates for optimization.
It is widely believed that the speed of the site depends only on the CMS ("engine"). Site owners often try to divide the CMS into fast and slow. In fact this is not true.
Of course, the load on the server depends on the code that is included in the used CMS. However, most popular systems try to optimize for maximum speed and fatal problems with the speed of the site should not be.
However, in addition to the main CMS code, the site may contain additional modules (plug-ins), extensions and modifications from the site developers. And already this code can have a negative impact on the speed of the site.
In addition, problems with speed occur when the system is used for other purposes. For example, a blogging system is used to create a store. Or a system for small sites is used to develop a portal.
The most powerful and universal means of increasing server speed is traditionally caching. Here we are talking about server caching, and not about caching headers. If the calculation of the result (page assembly, block) requires significant resources, we will put the result in the cache and we will periodically update it. The idea is simple and complex at the same time: caching systems are built into programming languages, site management systems and web servers.
As a rule, page caching allows you to reduce the page upload time to tens of milliseconds. Naturally, in this case, the server is easily experiencing peaks of attendance. There are two problems: not everything can be cached and the cache needs to be correctly disabled (reset). If problems are solved, caching can be recommended as an effective server acceleration tool.
In this part we have combined thin network optimizations that give server acceleration. The effect here is not as ambitious as in other methods, but is achieved solely by tuning, that is, free.
Tuning TCP today is required for large projects and servers with connections from 10G, the main thing to remember is that the network subsystem is regularly updated with the release of new Linux kernels, so it’s worth updating. Proper configuration of TLS (HTTPS) allows you to get a high level of security and minimize the time to establish a secure connection. Good recommendations issued by Mozilla .
The new version of the HTTP protocol - HTTP / 2 is designed to speed up the loading of sites. This protocol has appeared recently and is now actively used (about 20% of the share among websites). In general, HTTP / 2 does indeed have acceleration mechanisms, the main one is to reduce the effect of network delays on page load time (request multiplexing). But acceleration due to HTTP / 2 is not always successful, so you should not rely on this protocol.
Unlike server optimization, the client is focused on everything that happens in the user's browser. Because of this, control becomes more complicated (various devices and browsers) and many different directions of optimization arise. We will look at the most effective and universal methods that can be used in almost any project.
Critical rendering path (critical rendering path) - a set of resources to start drawing a page in the browser. As a rule, this list includes the HTML document itself, CSS styles, web fonts, and JS code.
Our task as speed optimizers is to shorten this path both in time (taking into account network delays) and in traffic (in order to take into account slow connections).
The easiest way to determine the critical path: run an audit in Chrome (in the developer’s panel), the Lighthouse plugin determines its composition and load time, taking into account the slow connection.
The main technique in reducing the critical path: remove everything that is not necessary or can be postponed. For example, most JS codes can be deferred until the page loads. To do this, we place the call to the JS resource at the end of the HTML document or use the async attribute.
For deferred loading of CSS, you can use dynamic styling through JS (waiting for the domContentLoaded event).
Connecting web fonts today has become almost a standard in design. Unfortunately, they negatively affect the speed of page rendering. Web fonts are additional resources that must be obtained before the text starts to be drawn.
The situation is worsened by the fact that often pointers to font files are buried in a CSS file, which also does not come instantly. Many developers like to use public services of web fonts (for example, Google Fonts), which causes even greater delays (additional connections, CSS-file).
Optimization rules are to reduce the size of web fonts traffic and get them as quickly as possible.
To reduce traffic, you need to use modern formats: WOFF2 for modern browsers, WOFF for compatibility. In addition, you need to include only those character sets that are used on the site (for example, Latin and Cyrillic).
You can affect the rapid display of web fonts using the new specifications link rel = "preload" and the CSS properties of the font-display. Preload will allow the browser to indicate the need to download a font file as early as possible, and the font-display gives you the flexibility to control the browser behavior in case of a file delay (wait, draw a spare, not wait for the font for more than three seconds)
Images make up the majority of the weight of a modern site. Of course, images are not such critical page resources as CSS and JS code. But for many sites, images make up an important part of the content: let's recall any product card in the online store.
The main method for optimizing images: reducing their size. To do this, use the correct format and compression tools:
In addition to these formats, new ones are being developed: for example, WebP from Google. This format can cover the use of PNG and JPEG - supports lossy and lossless compression, transparency and even animation. To use it, it is enough to create copies of images in WebP and give them to browsers that support them.
For PNG, there are many optimization tools that can be used to reduce the size, for example, OptiPNG, PNGout, ect and others. Also, internal optimization of data compression can be performed using zopfliPNG. The main idea of ​​such software is in the selection of optimal compression parameters, deleting unnecessary data from the file. Here you need to be careful: some utilities have a lossy mode, which may not be suitable for you (if you expect the exact same image at the output).
JPEG optimization is also divided into two types: lossy and lossless. In general, we can recommend the Mozilla JPEG package, which is specially designed for better compression in this format. For lossless optimization, you can use jpegtran, with losses - cjpeg.
This is the simplest method of client optimization. Its meaning is in browser caching of rarely changing resources: images, CSS and JS-files, fonts, sometimes even the HTML document itself. As a result, each resource is requested from the server only once.
If you use Nginx, just add the directive:
From this point on, the browser has the right to cache resources for up to a year (which is almost forever). The new parameter "immutable" says that the resource is not planned to change.
Of course, the question arises: what to do if we need to change the cached resource? The answer is simple: change its address, URL. For example, you can add a version in the file name. For HTML documents, this method is also applicable, but, as a rule, a shorter cache period is used (for example, one minute or an hour).
Mandatory practice is the compression of any text data during transmission from the server to the browser. Most web servers have a gzip compression response implementation.
However, simple activation of compression is not enough.
First, the compression ratio is adjustable and should be close to the maximum.
Secondly, you can use static compression, that is, pre-compress files and put on the disk. Then the web server will look for a compressed version and immediately give it away. Third, you can use more efficient compression algorithms: zopfli (compatible with gzip) and brotli (new compression algorithm). Brotli will only work with https. Since these algorithms (especially zopfli) are expensive to compress, we definitely use them in a static version.
To maximize the effect of compression on files, the minification process is preliminarily applied: cleaning out unnecessary newlines, spaces, and other unnecessary characters. This process is specific to each format. You should also take care of the compression of other text data on the site.
The use of a CDN (content delivery network) to speed up sites is a highly advertised measure that has a lot of marketing husk around the essence of the technology.
CDNs were originally developed to offload Internet-based broadcast media sites. For example, when watching live video, several thousand viewers create a very large load on server bandwidth. In addition, to ensure uninterrupted quality of communication with a large distance of the client and server is extremely difficult (due to delays and network instability).
The solution to this problem was to create a CDN, that is, a distributed network to which clients connected (for example, viewers), and the hosts of this network already to the server (origin). At the same time, the number of connections to the server was reduced to one (several), and the number of connections to the CDN could reach millions by caching the content by the network.
Today, most CDNs position themselves as a means of speeding up websites, primarily by reducing the distance from the content to the client (site visitor).
How can I speed up a site using a CDN?
Yes, indeed, the user connects, as a rule, to the near (by access time) network server and gets a quick process of establishing TCP and TLS connections. Further, if the content is on the CDN server, the user can quickly get it. This reduces the load on our own server.
Secondly, a CDN can not just distribute content without changes, but optimize it on its side and give it in a more compact form: compress images, apply compression to a test, etc. Due to such optimizations, you can reduce download time.
Disadvantages, as usual, the continuation of the merits: the object may not be in the cache of the CDN node. For example, it has not been requested yet or it cannot be cached (HTML document). In this case, we get additional delays between the CDN node and our server.
Despite the fact that CDNs are designed to speed up access to the site, there may be situations where the network route will be less optimal than without a CDN. Especially important for global CDN, for which Russia is not a priority market.
Finally, content delivery networks are very complex systems in which failures, instability and other problems are also possible everywhere. Using CDN, we add another level of complexity.
Let's say you managed to achieve good speed indicators of the site. Users and owners of the resource are satisfied. On this you can forget about the issue of speed? Of course not. To achieve a permanent quality of the site, it is necessary to constantly maintain the site and monitor it.
Any live web project is regularly updated, changes occur both in common templates (themes, interfaces,) and content. Also the program code is actively changing (both client and server).
Each change can affect the speed of the site. To control this impact, you need to implement a synthetic site speed monitoring system at the development stage. Thus, speed problems can be intercepted before users notice them.
Optimizing incoming content requires the integration of optimizing procedures into a content management system. First of all, it concerns image processing.
The acceleration of sites is a very dynamic area: new standards are emerging, their browser support is changing. Therefore, it is important to regularly conduct a revision of the project technologies, processes and software used.
Synthetic testing under ideal laboratory conditions is very useful for assessing changes in the system code, but it is not enough. In the end, we want the site to work quickly with real users. To collect such data, there is a speed monitoring on the user side (RUM - real user monitoring).
To organize RUM, it is enough to connect one of the web analytics systems (Yandex.Metrica, Google Analytics) and view reports on the site load time. For more detailed and accurate data, you can use specialized speed monitoring services.
The site acceleration industry is a fairly young web development industry and is actively developing. The importance of speed sites for Internet business is already evident, it is becoming one of the factors of competition. That is why it is necessary to engage in optimizing the speed of the site and make investments in this area.
The topic of site speed is extensive and covers many aspects of developing and supporting a web application: from server code to content. This means that getting good results is impossible without involving the development team.
The most important thing: remember the users, take into account the various conditions of use of the site. Site acceleration is a process that occurs with varying intensity throughout the entire life cycle of a project.
Everyone knows that a slow site is bad. Because of the braking site, serious problems arise when solving everyday tasks. Sometimes it's just annoying. Often the braking of a site is a breakdown, a denial of service — people do not wait for the download and leave. This is true for cases of radical braking of the site, for example, when the start of page rendering begins 8–10 seconds after the click.
')
Even with a relatively favorable situation with the site (with fast downloads on the wired Internet and a modern computer), delays in the download can lead to loss of audience and a decrease in conversion. For example, Amazon conducted an experiment in which it found that every 100 ms (0.1 s) delays lead to a decrease in sales of 1%.
But more than half of Internet users today use mobile devices to access sites. So they can use slow access channels and processors to download the site.
The third reason for the importance of the site speed question is technical. As a rule, slow websites consume an increased amount of hosting resources, which leads to additional costs. Server-side brakes reduce the ability to relive the peak load on the site without any problems.
Therefore, the speed of the site should be dealt with both from a technical and economic point of view. In this article we will focus on the technical side of speeding up sites.
Site speed: main components
The speed of the site concerns two sides: client and server. Today, each of these parts is equivalent for the final result. But each with its own characteristics.
To understand what forms the load time of the page, we analyze this process into stages. As a result, we can understand where the server and client optimization capabilities are located.
The full process of loading the site (first visit) is as follows:
- DNS query by site name.
- Connecting to server by IP (TCP connection).
- Establish a secure connection using HTTPS (TLS connection).
- HTML page request by URL and server wait. (HTTP request)
- Download HTML.
- Parsing an HTML document on the browser side, queuing requests for document resources.
- Loading and parsing CSS styles.
- Download and execute js code.
- Begin page rendering, JS code execution.
- Download web fonts.
- Upload images and other items.
- End of page rendering, execution of deferred JS code.
In this process, some positions occur in parallel, some may change places, but the essence remains the same.
Server optimization deals with stages one through four, inclusive. Stages 5 through 12 are client optimization. The time spent on each of these stages is individual for each site, so you need to get site metrics and identify the main source of problems. And here we come to the question of how to get and interpret these metrics.
Site speed measurement
The main question: what should be measured? There are many metrics on the speed of sites, but there are not so many main ones.
First, this time to the first byte (TTFB - time to first byte) is the time from the start of the download process to the receipt of the first portion of data from the server. This is the main metric for server optimization.
Secondly, this is the beginning of the page rendering (start render, first paint). The metric shows the time until the end of the “white screen” period in the browser when the page begins to be drawn.
Thirdly, it is loading the main elements of the page (load time). This includes loading and interpreting all resources for working with the page, after this mark the page loading indicator stops spinning.
Fourthly, this is a full page load: the time until the end of the main activity of the browser, all main and deferred resources are loaded.
These basic metrics are measured in seconds. It is also useful to have an estimate of the traffic volume for the third and fourth metrics. Traffic needs to be known to evaluate the effect of connection speed on load time.
Now you need to understand how to test the speed. There are many services and tools for assessing the metrics of the speed of loading sites, each of which is better for its task.
One of the most powerful tools is the developer panel in the browser. The most advanced functionality of the panel in Chrome. On the Network tab, you can get metrics on the load time of all elements, including the HTML document itself. When you hover over an item, you can find out how much time is spent on each stage of obtaining a resource. To evaluate the full picture of the page loading process, you can use the Performance tab, which gives full details up to the decoding time of pictures.
If you need to estimate the speed of the site without full details, it is useful to start the site audit (Audits tab), it will be performed using the Lighthouse plugin. In the report, we get a speed estimate for mobile devices (both integral in points, and according to our main metrics) and several other reports.
Among web services, the WebPagetest system has become the professional standard. This service loads the site in real browsers with a given type of connection and generates a detailed report on all stages and metrics.
For a quick assessment of client optimization, you can use the Google PageSpeed ​​Insights service, but you need to remember that it does not include most of the most important metrics on load time. Finally, it is useful to analyze the site load time for real users. For this there are special reports in the Yandex.Metricka and Google Analytics web analytics systems.
Landmarks for site loading times are as follows: the beginning of rendering is about 1 second, the page loading is within 3-5 seconds. Within this framework, users will not complain about the speed of the site and the load time will not limit the effectiveness of the site. These figures should be reached precisely from real users, even in difficult conditions of mobile connection and outdated devices.
Server optimization
We turn to the very acceleration of the site. Optimization of the server part is the most understandable and obvious measure for website developers. First, the server part is fairly easily monitored and controlled on the side of system administrators. Secondly, with serious problems with the response time of the server, the slowdown is noticeable to everyone, regardless of the connection speed or device.
While the causes of server side braking can be very diverse, there are typical places to look at.
Hosting (server resources)
This is the reason for the number one slowdown for small sites. For the current site load, there is simply not enough hosting resources (usually, this is the CPU and the speed of the disk system). If you can quickly increase these resources, it is worth a try. In some cases, the problem will be solved. If the cost of additional resources becomes higher than the cost of work on optimization, it is necessary to proceed to the following methods.
DBMS (database server)
Here we turn to solving the source of the problem: low speed of the program code. Often most of the time a web application spends on queries to the database. This is logical, because the task of a web application is reduced to collecting data and transforming them according to a specific pattern.
The solution to the problem of slow responses from the database is usually divided into two stages: tuning the DBMS and optimizing queries and data schemas. Tuning a DBMS (for example, MySQL) can give acceleration several times, if the tuning has not been done before. Subtle tuning can give an effect within ten percent.
Optimizing queries and data schemas is a radical way to accelerate. Due to this optimization, it is possible to obtain acceleration by several orders of magnitude. If a change in the structure of the database can occur without intrusion into the program code of the site, then query optimization will require such intervention.
To identify slow queries, you need to collect statistics on the load on the database for a fairly long period of time. Further analysis of the log and the identification of candidates for optimization.
CMS and software code influence
It is widely believed that the speed of the site depends only on the CMS ("engine"). Site owners often try to divide the CMS into fast and slow. In fact this is not true.
Of course, the load on the server depends on the code that is included in the used CMS. However, most popular systems try to optimize for maximum speed and fatal problems with the speed of the site should not be.
However, in addition to the main CMS code, the site may contain additional modules (plug-ins), extensions and modifications from the site developers. And already this code can have a negative impact on the speed of the site.
In addition, problems with speed occur when the system is used for other purposes. For example, a blogging system is used to create a store. Or a system for small sites is used to develop a portal.
Caching
The most powerful and universal means of increasing server speed is traditionally caching. Here we are talking about server caching, and not about caching headers. If the calculation of the result (page assembly, block) requires significant resources, we will put the result in the cache and we will periodically update it. The idea is simple and complex at the same time: caching systems are built into programming languages, site management systems and web servers.
As a rule, page caching allows you to reduce the page upload time to tens of milliseconds. Naturally, in this case, the server is easily experiencing peaks of attendance. There are two problems: not everything can be cached and the cache needs to be correctly disabled (reset). If problems are solved, caching can be recommended as an effective server acceleration tool.
Optimization TCP, TLS, HTTP / 2
In this part we have combined thin network optimizations that give server acceleration. The effect here is not as ambitious as in other methods, but is achieved solely by tuning, that is, free.
Tuning TCP today is required for large projects and servers with connections from 10G, the main thing to remember is that the network subsystem is regularly updated with the release of new Linux kernels, so it’s worth updating. Proper configuration of TLS (HTTPS) allows you to get a high level of security and minimize the time to establish a secure connection. Good recommendations issued by Mozilla .
The new version of the HTTP protocol - HTTP / 2 is designed to speed up the loading of sites. This protocol has appeared recently and is now actively used (about 20% of the share among websites). In general, HTTP / 2 does indeed have acceleration mechanisms, the main one is to reduce the effect of network delays on page load time (request multiplexing). But acceleration due to HTTP / 2 is not always successful, so you should not rely on this protocol.
Client Optimization
Unlike server optimization, the client is focused on everything that happens in the user's browser. Because of this, control becomes more complicated (various devices and browsers) and many different directions of optimization arise. We will look at the most effective and universal methods that can be used in almost any project.
Critical Path Optimization: CSS, JS
Critical rendering path (critical rendering path) - a set of resources to start drawing a page in the browser. As a rule, this list includes the HTML document itself, CSS styles, web fonts, and JS code.
Our task as speed optimizers is to shorten this path both in time (taking into account network delays) and in traffic (in order to take into account slow connections).
The easiest way to determine the critical path: run an audit in Chrome (in the developer’s panel), the Lighthouse plugin determines its composition and load time, taking into account the slow connection.
The main technique in reducing the critical path: remove everything that is not necessary or can be postponed. For example, most JS codes can be deferred until the page loads. To do this, we place the call to the JS resource at the end of the HTML document or use the async attribute.
For deferred loading of CSS, you can use dynamic styling through JS (waiting for the domContentLoaded event).
Web Font Optimization
Connecting web fonts today has become almost a standard in design. Unfortunately, they negatively affect the speed of page rendering. Web fonts are additional resources that must be obtained before the text starts to be drawn.
The situation is worsened by the fact that often pointers to font files are buried in a CSS file, which also does not come instantly. Many developers like to use public services of web fonts (for example, Google Fonts), which causes even greater delays (additional connections, CSS-file).
Optimization rules are to reduce the size of web fonts traffic and get them as quickly as possible.
To reduce traffic, you need to use modern formats: WOFF2 for modern browsers, WOFF for compatibility. In addition, you need to include only those character sets that are used on the site (for example, Latin and Cyrillic).
You can affect the rapid display of web fonts using the new specifications link rel = "preload" and the CSS properties of the font-display. Preload will allow the browser to indicate the need to download a font file as early as possible, and the font-display gives you the flexibility to control the browser behavior in case of a file delay (wait, draw a spare, not wait for the font for more than three seconds)
Image Optimization
Images make up the majority of the weight of a modern site. Of course, images are not such critical page resources as CSS and JS code. But for many sites, images make up an important part of the content: let's recall any product card in the online store.
The main method for optimizing images: reducing their size. To do this, use the correct format and compression tools:
- PNG for images with transparency and text;
- JPEG for photos and complex images;
- SVG for vector graphics.
In addition to these formats, new ones are being developed: for example, WebP from Google. This format can cover the use of PNG and JPEG - supports lossy and lossless compression, transparency and even animation. To use it, it is enough to create copies of images in WebP and give them to browsers that support them.
For PNG, there are many optimization tools that can be used to reduce the size, for example, OptiPNG, PNGout, ect and others. Also, internal optimization of data compression can be performed using zopfliPNG. The main idea of ​​such software is in the selection of optimal compression parameters, deleting unnecessary data from the file. Here you need to be careful: some utilities have a lossy mode, which may not be suitable for you (if you expect the exact same image at the output).
JPEG optimization is also divided into two types: lossy and lossless. In general, we can recommend the Mozilla JPEG package, which is specially designed for better compression in this format. For lossless optimization, you can use jpegtran, with losses - cjpeg.
Caching headers
This is the simplest method of client optimization. Its meaning is in browser caching of rarely changing resources: images, CSS and JS-files, fonts, sometimes even the HTML document itself. As a result, each resource is requested from the server only once.
If you use Nginx, just add the directive:
add_header Cache-Control "max-age=31536000, immutable"; From this point on, the browser has the right to cache resources for up to a year (which is almost forever). The new parameter "immutable" says that the resource is not planned to change.
Of course, the question arises: what to do if we need to change the cached resource? The answer is simple: change its address, URL. For example, you can add a version in the file name. For HTML documents, this method is also applicable, but, as a rule, a shorter cache period is used (for example, one minute or an hour).
Data compression
Mandatory practice is the compression of any text data during transmission from the server to the browser. Most web servers have a gzip compression response implementation.
However, simple activation of compression is not enough.
First, the compression ratio is adjustable and should be close to the maximum.
Secondly, you can use static compression, that is, pre-compress files and put on the disk. Then the web server will look for a compressed version and immediately give it away. Third, you can use more efficient compression algorithms: zopfli (compatible with gzip) and brotli (new compression algorithm). Brotli will only work with https. Since these algorithms (especially zopfli) are expensive to compress, we definitely use them in a static version.
To maximize the effect of compression on files, the minification process is preliminarily applied: cleaning out unnecessary newlines, spaces, and other unnecessary characters. This process is specific to each format. You should also take care of the compression of other text data on the site.
Using CDN
The use of a CDN (content delivery network) to speed up sites is a highly advertised measure that has a lot of marketing husk around the essence of the technology.
Theory: why
CDNs were originally developed to offload Internet-based broadcast media sites. For example, when watching live video, several thousand viewers create a very large load on server bandwidth. In addition, to ensure uninterrupted quality of communication with a large distance of the client and server is extremely difficult (due to delays and network instability).
The solution to this problem was to create a CDN, that is, a distributed network to which clients connected (for example, viewers), and the hosts of this network already to the server (origin). At the same time, the number of connections to the server was reduced to one (several), and the number of connections to the CDN could reach millions by caching the content by the network.
Today, most CDNs position themselves as a means of speeding up websites, primarily by reducing the distance from the content to the client (site visitor).
Possible effects
How can I speed up a site using a CDN?
Yes, indeed, the user connects, as a rule, to the near (by access time) network server and gets a quick process of establishing TCP and TLS connections. Further, if the content is on the CDN server, the user can quickly get it. This reduces the load on our own server.
Secondly, a CDN can not just distribute content without changes, but optimize it on its side and give it in a more compact form: compress images, apply compression to a test, etc. Due to such optimizations, you can reduce download time.
Disadvantages of using CDN
Disadvantages, as usual, the continuation of the merits: the object may not be in the cache of the CDN node. For example, it has not been requested yet or it cannot be cached (HTML document). In this case, we get additional delays between the CDN node and our server.
Despite the fact that CDNs are designed to speed up access to the site, there may be situations where the network route will be less optimal than without a CDN. Especially important for global CDN, for which Russia is not a priority market.
Finally, content delivery networks are very complex systems in which failures, instability and other problems are also possible everywhere. Using CDN, we add another level of complexity.
We fix the result
Let's say you managed to achieve good speed indicators of the site. Users and owners of the resource are satisfied. On this you can forget about the issue of speed? Of course not. To achieve a permanent quality of the site, it is necessary to constantly maintain the site and monitor it.
Acceleration support
Any live web project is regularly updated, changes occur both in common templates (themes, interfaces,) and content. Also the program code is actively changing (both client and server).
Each change can affect the speed of the site. To control this impact, you need to implement a synthetic site speed monitoring system at the development stage. Thus, speed problems can be intercepted before users notice them.
Optimizing incoming content requires the integration of optimizing procedures into a content management system. First of all, it concerns image processing.
The acceleration of sites is a very dynamic area: new standards are emerging, their browser support is changing. Therefore, it is important to regularly conduct a revision of the project technologies, processes and software used.
Real user speed monitoring
Synthetic testing under ideal laboratory conditions is very useful for assessing changes in the system code, but it is not enough. In the end, we want the site to work quickly with real users. To collect such data, there is a speed monitoring on the user side (RUM - real user monitoring).
To organize RUM, it is enough to connect one of the web analytics systems (Yandex.Metrica, Google Analytics) and view reports on the site load time. For more detailed and accurate data, you can use specialized speed monitoring services.
findings
The site acceleration industry is a fairly young web development industry and is actively developing. The importance of speed sites for Internet business is already evident, it is becoming one of the factors of competition. That is why it is necessary to engage in optimizing the speed of the site and make investments in this area.
The topic of site speed is extensive and covers many aspects of developing and supporting a web application: from server code to content. This means that getting good results is impossible without involving the development team.
The most important thing: remember the users, take into account the various conditions of use of the site. Site acceleration is a process that occurs with varying intensity throughout the entire life cycle of a project.
Source: https://habr.com/ru/post/337842/
All Articles