Как выжать сотку из PageSpeed и не сойти с ума
Слушай, мы все там были. Ты вылизываешь код, оптимизируешь картинки, а Google PageSpeed всё равно тычет тебе в лицо красной зоной и ругается на «Long Main Thread Tasks» или «Reduce Unused CSS». Кажется, что это бесконечная битва, где CSS — твой главный враг. Но давай честно: CSS тормозит страницу не потому, что он тяжелый, а потому, что браузер тратит слишком много сил на его парсинг и отрисовку. Сегодня я расскажу, как перестать воевать с метриками и начать писать код, который браузер будет проглатывать мгновенно.
Как мы страдали раньше
Помнишь времена, когда мы судорожно вырезали «Critical CSS» и вставляли его инлайном в head? Это был сущий ад: поддерживать два набора стилей, следить за тем, чтобы ничего не дублировалось, и молиться, чтобы верстка не развалилась при динамической подгрузке остального конфига. А эти бесконечные попытки обмануть браузер с помощью z-index: 99999 и хаков с will-change на каждом втором элементе? Мы создавали тысячи слоев композитинга, которые в итоге просто съедали всю память смартфона пользователя. Мы боролись с последствиями, а не с причиной, и в 2026 году смотреть на такие решения без слез просто невозможно.
Как делать правильно в 2026 году
Сегодня наша стратегия — это максимальная нативность и управление приоритетами браузера. Первым делом мы забываем про огромные монолитные бандлы. Используй каскадные слои @layer, чтобы четко разделить базовые стили, компоненты и сторонние библиотеки. Это избавляет от специфичности («войны селекторов») и позволяет браузеру быстрее строить дерево стилей.
Вторая киллер-фича — свойство content-visibility. Это просто магия для длинных лендингов. Ты буквально говоришь браузеру: «Эй, не рендери этот футер или нижние блоки, пока пользователь до них не долистает». Это экономит кучу времени на этапе Layout и Paint. Если ты уже используешь нативный CSS Nesting, твой код станет еще чище и легче для парсинга, так как браузеры теперь обрабатывают вложенность эффективнее, чем старые препроцессоры.
И не забывай про контейнерные запросы (Container Queries). Они позволяют избежать лишних перерисовок всего окна (Viewport), так как компоненты теперь адаптируются под размер своего контейнера, что локализует расчеты геометрии и повышает общую плавность интерфейса.
Готовый сниппет кода
Давай закрепим теорию практикой. Вот пример современной структуры CSS, которая заставит PageSpeed улыбаться:
/* 1. Группируем слои для управления приоритетами */
@layer base, components, utilities;
@layer base {
body {
font-family: system-ui;
/* Используем contain-intrinsic-size для предотвращения прыжков контента */
content-visibility: auto;
contain-intrinsic-size: 1px 5000px;
}
}
/* 2. Оптимизируем сложные блоки, которые не видны сразу */
.footer-complex-section {
content-visibility: auto;
contain-intrinsic-size: auto 400px;
}
/* 3. Используем современные фичи для чистоты кода */
@layer components {
.card {
display: grid;
gap: 1rem;
& .title {
font-weight: 700;
/* Локальные переменные работают быстрее глобальных */
--card-accent-color: oklch(65% 0.2 260);
color: var(--card-accent-color);
}
}
}
Частая ошибка новичков
Главный факап, который я вижу постоянно — это бездумное использование content-visibility: auto для элементов, которые находятся «выше складки» (above the fold). Если ты применишь это свойство к шапке или первому экрану, ты получишь обратный эффект: PageSpeed влепит тебе штраф за LCP (Largest Contentful Paint), потому что браузер возьмет паузу перед отрисовкой критически важного контента. Запомни: оптимизируем только то, что пользователь увидит спустя пару секунд скролла. И никогда, слышишь, никогда не используй @import внутри CSS-файлов — это убивает параллельную загрузку и гарантированно срезает тебе 20-30 баллов в мобильной версии.
🔥 Больше фишек, готовых сниппетов и передовых подходов к CSS мы публикуем в нашем Telegram-канале. Подписывайтесь, чтобы не пропустить!