Web performance: Why Performance Matters
How to make a site that the user likes? What should it be: beautiful, with easy navigation, with a memorable URL? First of all, the site should not slow down - the user should get the impression that everything is flying. This is primary. Everything else is solved as development. About how the site is perceived by users, what it depends on and when performance decides, we talked with Denis Mishunov , a frontend developer (formerly a contributor to CMS Plone as part of Plone UI Team), the author of articles about Smashing Magazine performance and an active speaker at professional conferences (including From The Front, JSConf EU, JSConf Budapest, Smashing Conference, and now HolyJS )
- Tell us about yourself. What was the path to web development, why exactly? What are you doing now?
')
- Before what is now called web development, I reached quickly, confidently and predictably: the first computer, the first, useless, site, the awareness of frailty of being. Next was the reading of the first pages of “Perl Programming” by Larry Will and Tom Christiansen with a depressed camel on the cover, a renewed awareness of the frailty of life and, as a result, the postponing of a camel book. And then I discovered Jeffrey Zeldman 's Designing with Web Standards . Then there was, of course, Lebedev's “Kovodstvo” and a lot of the rest. But Zeldman’s book was a turning point. I would like to say something beautiful like: “the world of the web captured me after reading”, but in fact I just realized that compared to “designer of electronic devices” (which of us tried in vain to do at the institute), the Internet developer, namely, it was called so at the beginning of the zero, it sounds frankly steeper.
After that, we were searching for ourselves in many years of working with Plone's content management system, working on sites of large and not-so-well companies, another awareness of frailty of being and, as a result, moving to Norway.
Now I work in a small but very ambitious company Digital Garden AS , where I head the front-end development department. I am engaged in architecture and implementation of the whole stack of front-end technologies from A to Ă…, as we say in Norway. Our department is friendly and consists only of me. Therefore, conflicts are kept to a minimum, although differences sometimes arise.
- Tell me about the "symptoms of inhibition." Where to start looking for reasons right away, and where to look at last?
“The main symptom of inhibition is inhibition.” This can be quoted. More seriously, the types of performance problems may be different and, accordingly, they need to be solved in different ways. But, most likely, the loss of performance either occurs gradually: you load more and more code that is getting worse and worse optimized in the browser; or the loss of performance occurs instantly, and, accordingly, the reasons must be sought in the last commit, the last upload to the server, and so on. In the latter case, the recipe is simple - roll back to the previous version and thoroughly test the latest changes before re-loading into the project. In the case of a gradual loss of productivity, things are more complicated, but on the topic of writing high-quality code and its optimization of information on the Internet at the moment there are more than photos of cats, and discussing this is not quite a gratifying matter - everyone has their own recipe for high-quality code.
- Who is most often to blame for the decrease in performance: frontend or backend?
- You know, like any other problem, the decline in productivity cannot be considered one-sided and say that one or the other is to blame. Any medal has two sides. There are problems on the server side: for example, requests to the API are processed too long, or the response itself due to a non-optimal architecture comes from the server too slowly. But, as practice shows, all these “troubles” on the server should not be the cause of a slow interface, and the front end should be ready to “lend” at such a moment. How this should happen depends on the situation. At the beginning of June in St. Petersburg, within the framework of the HolyJS conference , I will present the report “Chasing Performance. Psychology of the user "in which I will tell about some such moments.
- Let's say the site is ready, but problems are gradually being identified. How to disguise them in front of the user while fixes are being added?
- Do not wait - run the project, and your users will tell you where to mask the problems, rest assured. And depending on the problem, you will understand how to disguise it. I understand that not all projects can afford such an approach. And developers, as a rule, have extremely vulnerable souls, and minimal criticism plunges them into depression. I, probably, and such. However, without testing for real users, be they testers or end users, the assumption that what matters to the user and what does not, remains at the level of speculation. Needless to say, this is if we are talking about performance, and not about obvious problems such as server failures, a lot of errors in the JS console and other "charms".
- Could performance affect third-party code? For example, counters (on the website), widgets (in the case of an application). Who is guilty? How to get around?
- And again, "Who is to blame?" This is a sacred question for a Russian person. For some reason, it is much more important than “What to do?”, Although it is a noble cause to look for the guilty. In fact, there is a reality into which it is necessary to fit in, and in this case we have the following:
As you can see, there is no one to blame - you yourself decided that this widget is needed, and you yourself “screwed” it, reducing its performance. So the question “What to do?” In this case is much more relevant, but the possible answers to it are extremely simple and, I am sure, familiar to most of Habr's readers.
First of all, asynchrony is to load third-party widgets without locking the page. If you do not use any AMD loader like require.js, and write the script directly, then all modules not involved in the construction of the page should be loaded with the async parameter. Support for this attribute is sufficient for a modern application. For browsers that do not support async , you can use the classic version of asynchronous loading of widgets .
For more complex dependencies and tasks, you can use the Service Worker or Web Workers API.
- How is performance related to website or application design?
- Sometimes developers try to shift the blame for the low productivity of their projects to anything, including design (back to the question “Who is to blame?”). We all heard stories like: "Oh, our designer has such big pictures rolled up on the site ..." or "Well, you, our server gives an answer only for 5 seconds ..." - which supposedly should explain the low performance. Often, this means: “I don’t have time to do any nonsense - I'd better go and screw in a new framework.” Yes, a lot of things affect performance, but this does not mean that this should somehow affect your users. Use the user's psychology to “close holes” and gain time for a real fix to real problems. How specifically, I will talk about this in my report in St. Petersburg.
Oh yes! And there is no connection between performance and design. Only ts-with-ss-about it to anyone.
- Recommend a technology stack for developing a web application? Are there universal approaches?
- I will recommend the stack with which the developer feels comfortable. No need to chase buzzwords and take on everything that today's industry feeds us - time and effort to cover all the new items is never enough. Before transferring the frontend to a new stack, for example, ask yourself: “What does not suit the stack that already exists?” If the answers end in: “The stack is outdated”, then you can calm down and learn new technologies, tools and frameworks touching the main project, performing its functions. If there really is a need to change something: security, complexity or impossibility of maintaining the code (for example, the developer of the current version has quit, and the new developer is not familiar with the current solution or feels like other technology like fish in water), and so on, here, too, decisions must be made carefully, without driving oneself or oneself into a corner.
If the developer feels more comfortable with pure languages ​​and technologies like Javascript and CSS without libraries - fine. In most cases, this gives you complete control and understanding of what is happening “under the hood” of the project. But this control comes, respectively, due to the large loss of time during development - you have to reinvent the wheel again and again. To solve this problem, we have frameworks, libraries, compilers, and other animals. Which one to choose is a rhetorical question. The developer should psychologically get used to the idea of ​​delegating some tasks to a certain uncontrolled or poorly controlled object. Moreover, the developer must understand that support for the framework may end, the new version may break the old code, anything may happen . Such an approach, as a rule, saving development time, however, either dictates the style of writing applications, or lowers the productivity of the application, or leaves some other imprint on the development processes and the projects themselves.
So it all depends on the flexibility and preferences of the developer. For example, I feel quite comfortable continuing to write frontend applications on Backbone. When I mentioned this during the panel discussion on the future of Javascript at the FDConf in Minsk in April, I caught a lot of sympathetic views, as if I had been forced to test under IE6. Nevertheless, it is more comfortable for me to support the project on Backbone, with which we have been for several years, rather than rushing from Angular to the reactor, darting between different versions, and wasting energy, updating code that does not work in the new version. It is easier for me to switch to pure Javascript in existing projects than to transfer them to another bazvord for no reason. Maybe it's age :)
My development tools stack contains:
However, for new projects I, of course, look at new technologies and study them in order to understand what might fit in my vision of development and what not. For example, in parallel, I am engaged in the implementation of web components on Polymer in different, not heavily loaded sections of code, since the idea of ​​such components corresponds to my vision of code organization.
- Which web applications are most often affected by performance degradation? Why?
- There is no particular category of applications more or less prone to performance problems. The main barrier to productivity often lies between the chair and the keyboard. However, some applications are harder to optimize in terms of performance. For example, applications like aggregators for searching air tickets or selecting tours with long and voluminous queries to the database. Ideas on how to cope with the problems of waiting in case you can not optimize the technical side of the issue, I reveal in the third part of my article “Why Performance Matters” in Smashing Magazine.
- How to test the performance of the web, which metrics should please, and which should be alarming?
- For me, the main parameter that I always control is the time before drawing starts (RUM First Paint for those who use webpagetest.org ).
Many have a separate budget for performance, which limits the maximum amount of data of various types in order for performance to be on par. There are tools like performancebudget.io that allow you to get such a budget. But first of all, you need to understand where the figures for such a budget come from , what the page load time limits are based on and so on.
- What applications on the web, in your opinion, are close to perfection and delight you? Why?
- I am pleased with the applications that work. Which are predictable. If they are also beautiful, everything is fine. But as soon as aesthetics begins to prevail over content, it becomes boring, and if there are alternative projects, then it is generally useless.
- If something slows down, hangs and does not open - is the root cause of poorly written code or is everything not so banal?
- Probably, if “something slows down, hangs and does not open,” then the reason is most likely in physiology. But if we are talking about web projects, there can be a lot of reasons - from simple try ... catch to Javascript (not optimized by the compiler) to, of course, server delays. Any performance issues are considered in the context of a separate project.
- The levels of applications and sites are different: from the application for friends to loaded services. When to start bothering about performance?
- You yourself will understand when. But, most likely, you should not bother at all. It is necessary to soberly assess the scale of the problem in order to apply an adequate solution. For example, if a new feature that you uploaded to your site slows it down, say, by 100 milliseconds, you don’t need to rush into battle and regain that time. Consider, and the user will notice this slowdown? Does it play any role for him? Does this play any significant role for ranking your site in search results? Despite the fact that performance is very important in modern applications, we often spend energy on minor things that have no meaning for anyone other than our ego.
- The theme of your future report sounds nontrivial, can not wait to find out details. At the conference, you will talk about how to control the user's perception. Like this? Are these techniques, pure psychology or something at the junction? Tell me about it.
- In fact, only the name is nontrivial. And in fact, everything is quite simple: the performance that we measure in milliseconds, kilobytes, the number of requests to the server, and so on, often differs from how the user perceives your site. But, as strange as it may sound, we, as developers, are able to influence this perception. For example, the site uniweb.no in order to download 1.8 MB of content with 70 server requests from Moscow on an average Internet connection (1.5 MB / s) takes 19.476 seconds . However, if you download this site in your browser, you absolutely will not notice these seconds. Try it.
Everything that we see around us is the result of our perception, our brain processes information around us, and what we “see” is only a consequence of this processing. In this report, I will use examples to explain the basics of what psychological performance optimization is, how it works, what methods to manage user perception exist, and how to use them in front-end development.
- I can not even believe that it is not only on the side of the site. How to influence perception? Reveal the secrets.
- Ways to influence the perception of a person mass: iron, soldering iron, various prohibited drugs, in the end. But seriously, there are no secrets here, but there are certain techniques for managing user perception. I tell you more about this in the already mentioned “Why Performance Matters” series of articles. I am sure that an inquisitive reader will get a lot of useful information from them. And those who are too lazy to read, can get first-hand information at the conference ... well, you already know.
- In general, how does the user see the site? How does his look differ from the look of a developer? What is important to the user, and on what he will not focus?
- The user is such a “black box”. You never know what is going on inside it. Accordingly, it is never known what is really important for each individual user. Each of them is in its context: it can be in a hurry, and can sit quietly, lounging on the sofa; He can search for something specific, or he can simply browse all the products available in your online store. All of these users will have a different perception of your project. Unfortunately, you can not make a project that will work the same for all, and you need to take it for granted. Nevertheless, psychology is the common denominator that unites such different users.
Psychologically, the time we have in the head is usually different from the real time on the clock.
- Denis, finally share some short checklist with critical frontend problems that you must have for each developer?
- Information on this topic on the Internet mass. About her does not write except that lazy. But in short, it all comes down to some such option:
In April of this year, after consulting with many experts on performance optimization , KeyCDN collected a good list of parameters and techniques to help keep performance under control.
But you need to understand the main thing - as I said earlier, every project you work with is unique, and there are no universal solutions for the whole range of possible problems that you will encounter. There are some basic things that you just need to understand and, based on this understanding, to take this or that decision. Therefore, the most important advice that I can give to readers is to think and do not try to apply everything in your projects about what is written in articles, tutorials, and so on. Instead, try to understand why this is so and not otherwise. In the end, your projects are often not a field for experimentation, but a working organism that must continue to work.
We are waiting for everyone who wants to hear the details of Denis's report and listen to other speakers on the topic of web-development at the JavaScript conference of HolyJS on June 5 in St. Petersburg. We do not know about the weather, but it will be hot here!
PS: drawings in the post - Denis Mishunov
- Tell us about yourself. What was the path to web development, why exactly? What are you doing now?
')
- Before what is now called web development, I reached quickly, confidently and predictably: the first computer, the first, useless, site, the awareness of frailty of being. Next was the reading of the first pages of “Perl Programming” by Larry Will and Tom Christiansen with a depressed camel on the cover, a renewed awareness of the frailty of life and, as a result, the postponing of a camel book. And then I discovered Jeffrey Zeldman 's Designing with Web Standards . Then there was, of course, Lebedev's “Kovodstvo” and a lot of the rest. But Zeldman’s book was a turning point. I would like to say something beautiful like: “the world of the web captured me after reading”, but in fact I just realized that compared to “designer of electronic devices” (which of us tried in vain to do at the institute), the Internet developer, namely, it was called so at the beginning of the zero, it sounds frankly steeper.
After that, we were searching for ourselves in many years of working with Plone's content management system, working on sites of large and not-so-well companies, another awareness of frailty of being and, as a result, moving to Norway.
Now I work in a small but very ambitious company Digital Garden AS , where I head the front-end development department. I am engaged in architecture and implementation of the whole stack of front-end technologies from A to Ă…, as we say in Norway. Our department is friendly and consists only of me. Therefore, conflicts are kept to a minimum, although differences sometimes arise.
- Tell me about the "symptoms of inhibition." Where to start looking for reasons right away, and where to look at last?
“The main symptom of inhibition is inhibition.” This can be quoted. More seriously, the types of performance problems may be different and, accordingly, they need to be solved in different ways. But, most likely, the loss of performance either occurs gradually: you load more and more code that is getting worse and worse optimized in the browser; or the loss of performance occurs instantly, and, accordingly, the reasons must be sought in the last commit, the last upload to the server, and so on. In the latter case, the recipe is simple - roll back to the previous version and thoroughly test the latest changes before re-loading into the project. In the case of a gradual loss of productivity, things are more complicated, but on the topic of writing high-quality code and its optimization of information on the Internet at the moment there are more than photos of cats, and discussing this is not quite a gratifying matter - everyone has their own recipe for high-quality code.
- Who is most often to blame for the decrease in performance: frontend or backend?
- You know, like any other problem, the decline in productivity cannot be considered one-sided and say that one or the other is to blame. Any medal has two sides. There are problems on the server side: for example, requests to the API are processed too long, or the response itself due to a non-optimal architecture comes from the server too slowly. But, as practice shows, all these “troubles” on the server should not be the cause of a slow interface, and the front end should be ready to “lend” at such a moment. How this should happen depends on the situation. At the beginning of June in St. Petersburg, within the framework of the HolyJS conference , I will present the report “Chasing Performance. Psychology of the user "in which I will tell about some such moments.
- Let's say the site is ready, but problems are gradually being identified. How to disguise them in front of the user while fixes are being added?
- Do not wait - run the project, and your users will tell you where to mask the problems, rest assured. And depending on the problem, you will understand how to disguise it. I understand that not all projects can afford such an approach. And developers, as a rule, have extremely vulnerable souls, and minimal criticism plunges them into depression. I, probably, and such. However, without testing for real users, be they testers or end users, the assumption that what matters to the user and what does not, remains at the level of speculation. Needless to say, this is if we are talking about performance, and not about obvious problems such as server failures, a lot of errors in the JS console and other "charms".
- Could performance affect third-party code? For example, counters (on the website), widgets (in the case of an application). Who is guilty? How to get around?
- And again, "Who is to blame?" This is a sacred question for a Russian person. For some reason, it is much more important than “What to do?”, Although it is a noble cause to look for the guilty. In fact, there is a reality into which it is necessary to fit in, and in this case we have the following:
- On the site you need to tie * the necessary * widget;
- the widget often slows down the speed of the site;
As you can see, there is no one to blame - you yourself decided that this widget is needed, and you yourself “screwed” it, reducing its performance. So the question “What to do?” In this case is much more relevant, but the possible answers to it are extremely simple and, I am sure, familiar to most of Habr's readers.
First of all, asynchrony is to load third-party widgets without locking the page. If you do not use any AMD loader like require.js, and write the script directly, then all modules not involved in the construction of the page should be loaded with the async parameter. Support for this attribute is sufficient for a modern application. For browsers that do not support async , you can use the classic version of asynchronous loading of widgets .
For more complex dependencies and tasks, you can use the Service Worker or Web Workers API.
- How is performance related to website or application design?
- Sometimes developers try to shift the blame for the low productivity of their projects to anything, including design (back to the question “Who is to blame?”). We all heard stories like: "Oh, our designer has such big pictures rolled up on the site ..." or "Well, you, our server gives an answer only for 5 seconds ..." - which supposedly should explain the low performance. Often, this means: “I don’t have time to do any nonsense - I'd better go and screw in a new framework.” Yes, a lot of things affect performance, but this does not mean that this should somehow affect your users. Use the user's psychology to “close holes” and gain time for a real fix to real problems. How specifically, I will talk about this in my report in St. Petersburg.
Oh yes! And there is no connection between performance and design. Only ts-with-ss-about it to anyone.
- Recommend a technology stack for developing a web application? Are there universal approaches?
- I will recommend the stack with which the developer feels comfortable. No need to chase buzzwords and take on everything that today's industry feeds us - time and effort to cover all the new items is never enough. Before transferring the frontend to a new stack, for example, ask yourself: “What does not suit the stack that already exists?” If the answers end in: “The stack is outdated”, then you can calm down and learn new technologies, tools and frameworks touching the main project, performing its functions. If there really is a need to change something: security, complexity or impossibility of maintaining the code (for example, the developer of the current version has quit, and the new developer is not familiar with the current solution or feels like other technology like fish in water), and so on, here, too, decisions must be made carefully, without driving oneself or oneself into a corner.
If the developer feels more comfortable with pure languages ​​and technologies like Javascript and CSS without libraries - fine. In most cases, this gives you complete control and understanding of what is happening “under the hood” of the project. But this control comes, respectively, due to the large loss of time during development - you have to reinvent the wheel again and again. To solve this problem, we have frameworks, libraries, compilers, and other animals. Which one to choose is a rhetorical question. The developer should psychologically get used to the idea of ​​delegating some tasks to a certain uncontrolled or poorly controlled object. Moreover, the developer must understand that support for the framework may end, the new version may break the old code, anything may happen . Such an approach, as a rule, saving development time, however, either dictates the style of writing applications, or lowers the productivity of the application, or leaves some other imprint on the development processes and the projects themselves.
So it all depends on the flexibility and preferences of the developer. For example, I feel quite comfortable continuing to write frontend applications on Backbone. When I mentioned this during the panel discussion on the future of Javascript at the FDConf in Minsk in April, I caught a lot of sympathetic views, as if I had been forced to test under IE6. Nevertheless, it is more comfortable for me to support the project on Backbone, with which we have been for several years, rather than rushing from Angular to the reactor, darting between different versions, and wasting energy, updating code that does not work in the new version. It is easier for me to switch to pure Javascript in existing projects than to transfer them to another bazvord for no reason. Maybe it's age :)
My development tools stack contains:
- Backbone - for the main architecture and organization of applications;
- underscore - to simplify life;
- require.js - again, for the organization. Plus, not least, to optimize the code for production (r.js); node - mainly for writing scripts designed to solve some auxiliary tasks;
- Grunt - to build projects;
- Good old bash - since there are a lot of projects, and some of them have common modules, there is a problem of simultaneous assembly of all projects containing a modified module. Having rummaged with node to solve this problem, I came to the conclusion that node and git are not the best friends - NodeGit did not please me with simplicity. So I replaced the node-script with an understandable and predictable bash-script, which successfully updates everything, builds, loads everything with just one command for all projects at once. I just have to upgrade to the server side.
However, for new projects I, of course, look at new technologies and study them in order to understand what might fit in my vision of development and what not. For example, in parallel, I am engaged in the implementation of web components on Polymer in different, not heavily loaded sections of code, since the idea of ​​such components corresponds to my vision of code organization.
- Which web applications are most often affected by performance degradation? Why?
- There is no particular category of applications more or less prone to performance problems. The main barrier to productivity often lies between the chair and the keyboard. However, some applications are harder to optimize in terms of performance. For example, applications like aggregators for searching air tickets or selecting tours with long and voluminous queries to the database. Ideas on how to cope with the problems of waiting in case you can not optimize the technical side of the issue, I reveal in the third part of my article “Why Performance Matters” in Smashing Magazine.
- How to test the performance of the web, which metrics should please, and which should be alarming?
- For me, the main parameter that I always control is the time before drawing starts (RUM First Paint for those who use webpagetest.org ).
Many have a separate budget for performance, which limits the maximum amount of data of various types in order for performance to be on par. There are tools like performancebudget.io that allow you to get such a budget. But first of all, you need to understand where the figures for such a budget come from , what the page load time limits are based on and so on.
- What applications on the web, in your opinion, are close to perfection and delight you? Why?
- I am pleased with the applications that work. Which are predictable. If they are also beautiful, everything is fine. But as soon as aesthetics begins to prevail over content, it becomes boring, and if there are alternative projects, then it is generally useless.
- If something slows down, hangs and does not open - is the root cause of poorly written code or is everything not so banal?
- Probably, if “something slows down, hangs and does not open,” then the reason is most likely in physiology. But if we are talking about web projects, there can be a lot of reasons - from simple try ... catch to Javascript (not optimized by the compiler) to, of course, server delays. Any performance issues are considered in the context of a separate project.
- The levels of applications and sites are different: from the application for friends to loaded services. When to start bothering about performance?
- You yourself will understand when. But, most likely, you should not bother at all. It is necessary to soberly assess the scale of the problem in order to apply an adequate solution. For example, if a new feature that you uploaded to your site slows it down, say, by 100 milliseconds, you don’t need to rush into battle and regain that time. Consider, and the user will notice this slowdown? Does it play any role for him? Does this play any significant role for ranking your site in search results? Despite the fact that performance is very important in modern applications, we often spend energy on minor things that have no meaning for anyone other than our ego.
- The theme of your future report sounds nontrivial, can not wait to find out details. At the conference, you will talk about how to control the user's perception. Like this? Are these techniques, pure psychology or something at the junction? Tell me about it.
- In fact, only the name is nontrivial. And in fact, everything is quite simple: the performance that we measure in milliseconds, kilobytes, the number of requests to the server, and so on, often differs from how the user perceives your site. But, as strange as it may sound, we, as developers, are able to influence this perception. For example, the site uniweb.no in order to download 1.8 MB of content with 70 server requests from Moscow on an average Internet connection (1.5 MB / s) takes 19.476 seconds . However, if you download this site in your browser, you absolutely will not notice these seconds. Try it.
Everything that we see around us is the result of our perception, our brain processes information around us, and what we “see” is only a consequence of this processing. In this report, I will use examples to explain the basics of what psychological performance optimization is, how it works, what methods to manage user perception exist, and how to use them in front-end development.
- I can not even believe that it is not only on the side of the site. How to influence perception? Reveal the secrets.
- Ways to influence the perception of a person mass: iron, soldering iron, various prohibited drugs, in the end. But seriously, there are no secrets here, but there are certain techniques for managing user perception. I tell you more about this in the already mentioned “Why Performance Matters” series of articles. I am sure that an inquisitive reader will get a lot of useful information from them. And those who are too lazy to read, can get first-hand information at the conference ... well, you already know.
- In general, how does the user see the site? How does his look differ from the look of a developer? What is important to the user, and on what he will not focus?
- The user is such a “black box”. You never know what is going on inside it. Accordingly, it is never known what is really important for each individual user. Each of them is in its context: it can be in a hurry, and can sit quietly, lounging on the sofa; He can search for something specific, or he can simply browse all the products available in your online store. All of these users will have a different perception of your project. Unfortunately, you can not make a project that will work the same for all, and you need to take it for granted. Nevertheless, psychology is the common denominator that unites such different users.
Psychologically, the time we have in the head is usually different from the real time on the clock.
- Denis, finally share some short checklist with critical frontend problems that you must have for each developer?
- Information on this topic on the Internet mass. About her does not write except that lazy. But in short, it all comes down to some such option:
- Compression + optimization + decrease in the number of server requests. All this applies to both Javascript and CSS. About things like image optimization with ImageOptim, OptiPNG, and so on, I don’t even mention it separately. But it is worth mentioning the new element picture , which, being designed for adaptive solutions, nevertheless, reduces the load on the site.
- Control the time to start page rendering (RUM First Paint), as this is one of the most important parameters that characterize the performance of your site from the user's point of view.
- Minimizing the number of blocking elements. Asynchrony, asynchrony, asynchrony.
In April of this year, after consulting with many experts on performance optimization , KeyCDN collected a good list of parameters and techniques to help keep performance under control.
But you need to understand the main thing - as I said earlier, every project you work with is unique, and there are no universal solutions for the whole range of possible problems that you will encounter. There are some basic things that you just need to understand and, based on this understanding, to take this or that decision. Therefore, the most important advice that I can give to readers is to think and do not try to apply everything in your projects about what is written in articles, tutorials, and so on. Instead, try to understand why this is so and not otherwise. In the end, your projects are often not a field for experimentation, but a working organism that must continue to work.
We are waiting for everyone who wants to hear the details of Denis's report and listen to other speakers on the topic of web-development at the JavaScript conference of HolyJS on June 5 in St. Petersburg. We do not know about the weather, but it will be hot here!
PS: drawings in the post - Denis Mishunov
Source: https://habr.com/ru/post/282968/
All Articles