Top 5 reasons when JavaScript blocks the loading of your site

Based on observations, I have identified the 5 most problematic cases when JavaScript blocks the loading of the site.

Blocking scripts

Often, scripts from blocked social networks and sites are connected to sites. It could be:

One of the most frequent cases of blocking page loading is this facebook widget (the social network belongs to Meta, a company recognized as extremist in the Russian Federation).

1. A social network widget that displays group members.
2. Connecting the library script to integrate the “Share” button, which, in turn, connects the script of the banned social network.
3. Authorization script via a prohibited social network.

Access to these social networks is blocked through the DENY policy, not REJECT. This means that the user’s browser will send a request to download a JavaScript file and will not receive a response. Waiting for a response will “hang” from 30 to 45 seconds. After that, the browser will reset the connection.

If the script is loaded synchronously, and not asynchronously, then the window.onload event will be delayed for 30-45 seconds. This is due to the fact that window.onload waits for all JavaScript files of the page to load before working out.

Therefore, make sure that you do not connect files of prohibited social networks on the site. You can check their availability in 2 ways:

1. Disable all plug-ins in your browser that block ads and protect against tracking. Also disable the same protection in the browser settings. Open the page and check the suspended scripts in the developer tools.
2. Use the service [https://site.test/tools/page-checker ](Alarm website). Check for warnings in the “Blocking files” section.

Heavyweight services

There are files that can and should be connected on demand:

The total weight of all Google captcha files is 3.5 MB. It is loaded immediately, but is only used when the form is submitted directly.

1. Kartchi. The total amount of files uploaded by 1 captcha is about a megabyte. The correct solution would be to call a captcha at the time of filling out the form. That is, when the focus event is called for any field.
2. Video services. Use facades when displaying video inserts in video services. Here is [an example for youtube] (https://github.com/justinribeiro/lite-youtube ). The task of the facade is to postpone the heavy loading of the video player code. When you click on the video, the facade loads the player code. Up to this point, the facade displays only a preview of the video and the play button.
3. Authorization systems. Authorization systems like VK ID or Yandex ID are heavy. But they are used only on a special login page or in a pop-up window. Connect authorization system scripts on hold, at the time of demand, and not permanently.
4. Maps. If the cards are placed on the second screen of the page being opened and further, then they become visible to the user only after scrolling the page. Therefore, it makes no sense to download them immediately. It is better to load them in the window.onload event. Moreover, it is window.onload, not jQuery(document).ready or DOMContentLoaded, in order to load all the useful content of the site first.

You can check the connection of such files too early in https://site.test/tools/page-checker . The information will be in the sections “Premature file upload” and “Using JS facades”.

Counters of analytical systems

The tag documentation says that they should be connected in the head section as early as possible. But the counter scripts are heavy and require a lot of processor time to process. Yes, now all analytics systems load their scripts asynchronously, but because of their size, they still significantly delay page loading.

Counters can delay page loading from 0.15 to 0.5 seconds. This is despite the fact that the page should load in 1 second and faster.

Enable counters for analytics systems in the window.onload event. Except for Yandex Analytics. Because their session replay tool becomes more complete when collecting information about user actions starts as early as possible.

That’s just how easy it is to connect the Google counter postponed. It is enough to wrap it in the window.addEventListener function(“load”, function() {}); and load JavaScript through the function (taken from the Yandex tag).

<script>
window.addEventListener("load", function() {
    (function(m,e,t,r,i,k,a){m[i]=m[i]||function(){(m[i].a=m[i].a||[]).push(arguments)};
m[i].l=1*new Date();
for (var j = 0; j < document.scripts.length; j++) {if (document.scripts[j].src === r) { return; }}
k=e.createElement(t),a=e.getElementsByTagName(t)[0],k.async=1,k.src=r,a.parentNode.insertBefore(k,a)})
(window, document, "script", "https://www.googletagmanager.com/gtag/js?id=G-QWE123123", "ga");
    window.dataLayer = window.dataLayer || [];
    function gtag(){dataLayer.push(arguments);}
    gtag('js', new Date());

    gtag('config', 'G-QWE123123');
});
</script>

All statistical information about the stages of page loading is still taken from window.perfomance. Therefore, by enabling delayed counters, you are unlikely to affect the content of the final reports.

Location of the JS file call

Loading of all images located after JavaScript will be delayed.

All files on the page are loaded in the order they are declared in the HTML code. It is logical to load CSS files and images of the first screen of the page first of all. This is necessary in order to show the user at least some content as early as possible. This will keep his attention and will not give him a chance to get distracted or change the tab.

If you connect scripts first, and then CSS files, the page will be white for a few seconds. The first graphic will be displayed only after all JavaScript files in the queue have been loaded.

Therefore, scripts should be connected before the closing tag </body>, and not in the <head> section.

Long JS execution

Profiler looks loaded. But in fact, you can figure it out in 1 day.

Various large JavaScript files can take a long time to interpret (analogous to compiling in JS). Also, JavaScript files can simply take a long time to work out.

File 495972ac.js is used by 10%. Rather, only the plugin initialization function is called, and the functionality itself is not used.

To combat this, there are several ways:

1. Find the “Bottleneck” using the profiler. (firefox Profiler)[https://profiler.firefox.com/docs /], (chrome profiler)[https://developer.chrome.com/docs/devtools/performance?hl=ru].
2. Load scripts deferred. Pay special attention to the heavy scripts from the section of the same name in this post.
3. Locate unused files. Disable the grouping of JavaScript files in the site settings. Scan your site in https://site.test/tools/page-checker . Scroll to the “Extra JavaScript found” section. Pay attention to files where 90% of the code is not used. Most likely, their connection on the page can be avoided.
4. Clean up unused JavaScript in already existing files. How to do this is described in [this article] (/blog/neispolyzuemyy_javasscript_kod_poisk_i_udalenie).