В браузерах есть механизм блокирования рендеринга по каким-то событиям. Например, для синхронных скриптов браузер сначала их выполнит и только потом отдаст управление потоку отрисовки. Для стилевых таблиц работает так же. Это нужно, чтобы избегать FOUC — Flash of Unstyled Content.
Оказывается, в Chrome есть возможность задавать явно блокирование рендеринга для
link и script. Причём на этот раз не мимо спецификации. Если быть точнее, то атрибут blocking=render рекомендует браузеру блокировать рендеринга, пока скрипт или другой ресурс не скачается и не выполнится, если он исполняемый. Например, можно писать вот так:
<script id="async-script" blocking="render" async src="async-script.js"></script>
<script>
setTimeout(() => document.getElementById('async-script').blocking = '', 1500);
</script>
Такой код всё ещё загружает скрипт асинхронно, но при этом блокирует рендеринг первые 1.5 секунды загрузки приложения. Если соединение медленное, то возвращает дефолтный механизм с FOUC.
Полный текст эксплейнера: https://gist.github.com/xiaochengh/9404abbecdc3b45c0e9f3d5e99fbc65d
Спецификация: https://html.spec.whatwg.org/multipage/urls-and-fetching.html#blocking-attribute
Идея интересная, но не помню, чтобы про неё где-то рассказывали. Даже в release notes Chrome 105, где эту фичу, собственно, включили, ни слова. А ведь при помощи этого атрибута как будто можно хитро тюнить метрику CLS (сдвиг разметки) из Core Web Vitals. Аккуратно, конечно, чтобы не навредить пользователям ради метрик. То есть бездумно пихать этот атрибут где попало точно не стоит — в браузере всё-таки и так много встроенных эвристик, чтобы сделать пользователю хорошо, не нужно им мешать.
Кстати, судя по вот этому коммиту, в Firefox тоже этот атрибут скоро появится. От Safari их позицию узнаем уже только с релизом какого-нибудь Safari TP, заранее вряд ли.
https://chromestatus.com/feature/5452774595624960