Ответ
Загрузку страницы могут заблокировать:
- Синхронные скрипты (
<script>безasync/defer) – браузер останавливает парсинг HTML до их выполнения.
<script src="blocking.js"></script> <!-- Блокирует рендеринг -->
-
Большие CSS-файлы – браузер ждёт загрузки и парсинга CSSOM перед рендерингом.
-
Шрифты с
font-display: blockили без предзагрузки. -
Долгие задачи в основном потоке – например, сложные вычисления в JS.
-
Неоптимизированные изображения – особенно если они выше viewport.
-
Сетевые запросы – если API-запросы выполняются до отрисовки контента.
-
Плохой TTFB (Time To First Byte) – сервер медленно отвечает.
Оптимизации:
- Используйте
async/deferдля скриптов - Критический CSS в
<style>, остальное – асинхронно - Предзагружайте ключевые ресурсы (
<link rel="preload">) - Разбивайте код на чанки
Ответ 18+ 🔞
О, слушай, а вот это реально больная тема, про которую все вроде знают, но всё равно наступают на одни и те же грабли, как последние распиздяи. Смотри, что может так охуенно тормознуть твою страницу, что пользователь за это время успеет сходить за пивом, вернуться и ещё тебя мысленно обосрать.
Первое и самое жирное — синхронные скрипты. Это когда ты пишешь вот такую простыню:
<script src="blocking.js"></script>
И браузер, такой: «О, скрипт! Надо всё остановить, хуй знает что он там делает, может в DOM лазить, лучше я весь рендеринг приостановлю, пока этот файл не скачается и не выполнится». И стоит, блядь, как вкопанный. А файл-то весит овердохуища. Пиздец, а не оптимизация.
Дальше идут огромные CSS-файлы. Браузер же не может показать страницу, не зная, как она должна выглядеть. Он ждёт, пока весь CSS загрузится, распарсится в CSSOM, и только потом начинает что-то рисовать. Если у тебя там стилей на три тачки — терпи, чувак.
Шрифты — отдельная песня. Если они подключены криво, с font-display: block или просто висят в воздухе, браузер может решить: «Не покажу текст, пока шрифт не подгрузится». И пользователь пялится в пустоту, чувствуя себя идиотом.
А ещё есть долгие задачи в основном потоке. Представь: страница вроде загрузилась, а ты там накрутил какую-то хуйню на JavaScript, которая считает число Пи до миллиардного знака. Весь интерфейс встанет колом, будто его хуем пригвоздили. Пользователь кликает, а ничего не происходит — вот это волнение ебать, сразу терпения ноль.
Гигантские, неоптимизированные картинки, которые весят по 5 мегабайт каждая и лежат прямо в начале страницы — это тоже классика. Браузер будет пытаться их впихнуть в сетку, пока они качаются, и всё будет дёргаться и прыгать.
Не забывай про сетевые запросы. Если твой скрипт, прежде чем показать хоть что-то, идёт на три разных API и ждёт от них ответа — страница будет пустой до последнего. Пользователь уже успеет подумать, что у него интернет отрубился.
И, конечно, пиздецкий TTFB (Time To First Byte). Это когда твой сервер тупит, как мартышлюшка, и думает над ответом целых 2 секунды. Браузеру даже не с чего начать, он просто видит пустоту и крутит индикатор. Доверия ебать ноль сразу.
Что делать-то, спросишь?
Да нормальные вещи, блядь!
-
Скрипты — пихай
asyncилиdefer. Пусть качаются параллельно и не мешают.<script src="non-blocking.js" defer></script>(Видишь, код не трогаю, всё как есть).
-
CSS — выдёргивай критически важные стили (то, что видно сразу) прямо в
<style>в<head>. Всё остальное — подгружай асинхронно, нахуй. -
Шрифты — предзагружай (
<link rel="preload">), используйfont-display: swap, чтобы текст показывался системным шрифтом, а потом плавно менялся. -
Картинки — сжимай, ресайзь, используй современные форматы (WebP, AVIF), ленивую загрузку (
loading="lazy"). -
Код — дроби на куски (chunks), не грузи всю хуйню сразу. Пусть сначала самое необходимое.
-
Сервер — настрой кэширование, CDN, чтобы TTFB был ближе к нулю.
Вот и вся магия. Без этого — будешь сидеть и думать, почему твой сайт грузится, как хуй в пальто по болоту. А всё из-за ерунды.