Post Menu and Details.
Reading time: ~4 minutes
Get rid of unused JS code
By removing unused code from a project, not only will the browser load times for scripts be improved, but also the time it takes browsers to parse and compile the code. In order to get rid of unused code, you should pay attention to the peculiarities of the project. So, if you find some functionality that users do not work with, consider removing it from the project, and at the same time the associated JS code. As a result, the site will load faster, it will be faster to prepare for work in the browser.
Optimize your code for the environments in which it will run
In order to adequately evaluate the improvements made to the program, it is recommended to form a set of environments in which measurements can be made. In practice, you will not be able to perform code performance studies, for example, in all existing versions of JS engines, nor will you be able to optimize your code for all environments in which it can run. But it should be noted that testing code in any one environment is also not the best practice. This approach can give distorted results. Therefore, it is important to form a set of environments in which the code is most likely to run and to test projects in those environments.
Use memory sparingly
It is worth striving to ensure that web projects would use only the memory they absolutely cannot do without. The fact is that a developer cannot know in advance how much memory can be available to his application on a certain device. If an application uses large amounts of memory unreasonably, this creates an increased load on the memory management mechanisms of the browser JS engine. In particular, this concerns the garbage collector. Frequent calls to the garbage collector slow down programs. This negatively affects the usability of the project.
Avoid memory leaks
If your application has a memory leak, then this will translate into the fact that the loaded page will ask the browser for more and more memory. As a result, the memory consumption of this page can reach such a level that it will adversely affect the performance of the entire system. You have probably encountered a similar problem yourself (and you probably did not like it). It is possible that the page that had a memory leak contained some kind of image viewers, such as a slider or carousel.
Chrome developer tools can analyze your site for memory leaks. This is done by examining the indicators using the Performance tab. Usually, memory leaks come from fragments of the DOM removed from the page but bound to some kind of variable. This prevents the garbage collector from reclaiming data that was being occupied by unnecessary DOM fragments.
The Lighthouse tool can be recommended for exploring various aspects of web projects. He rates the application on the following indicators: Performance, Progressive Web App, Accessibility, Best Practices, SEO. Lighthouse gives recommendations for improving the project. Another performance analyzer, Google Page Speed, is designed to help developers research their sites and see where they can be improved. Both Lighthouse and Page Speed are not perfect tools, but using them helps you see problems that might not seem obvious at first glance.
Watch the variables
If you are accessing a DOM element multiple times, store the reference to it in a variable
Getting a reference to a DOM element is a slow operation. If you are going to access an element multiple times, it is best to store the reference to it in a local variable. But here it is important to remember that if the element, the reference to which is stored in the variable, is later removed from the DOM, you need to remove the reference to it from the variable as well. For example, you can do this by writing null to the variable. This will avoid memory leaks.
Strive to declare variables in the same scope in which they will be used
Users want web pages to load as quickly as possible. But it is unlikely that absolutely all the JS code of the project is needed for the initial display of the page. If the user needs to perform some action (for example, click on an element or go to any tab in the application) in order to use a certain code, then the loading of this code can be postponed by executing it after the initial loading of the page and the most important resources.
With this approach, it is possible to avoid loading and compiling a large amount of JS code by the browser at the very beginning of work, that is, to avoid slowing down the page output caused by the need to perform these operations. After all the essential downloads are complete, you can start downloading additional code. As a result, when the user needs this code, it will already be available to him. In line with the RAIL model, Google recommends lazy loading scripts with a duration of the order of 50ms. With this approach, code loading operations will not affect the user’s interaction with the page.
Thank you for reading!