Как CSS заменяет JavaScript: новые возможности CSS

Введение
В 2025 году CSS значительно расширил свои возможности, позволяя реализовывать функциональность, ранее доступную только через JavaScript. Это привело к упрощению кода, улучшению производительности и повышению доступности веб-приложений.

Позиционирование относительно якорных элементов
Функция Anchor Positioning позволяет размещать всплывающие подсказки и выпадающие списки относительно других элементов без использования JavaScript. Это упрощает создание интерактивных интерфейсов и снижает зависимость от сторонних библиотек.

Анимации, связанные с прокруткой
С появлением @scroll-timeline разработчики могут связывать прогресс анимации с прокруткой страницы, создавая сложные эффекты без необходимости писать JavaScript-код. Это улучшает производительность и делает анимации более плавными.

Код

/* Пример использования @scroll-timeline для анимации, связанной с прокруткой */
@scroll-timeline --scroll {
source: auto;
orientation: block;
}

.element {
animation: fade-in linear;
animation-timeline: --scroll;
}

@keyframes fade-in {
from { opacity: 0; }
to { opacity: 1; }
}

Пользовательские функции CSS
Пользовательские функции CSS позволяют создавать настраиваемые функции, которые возвращают значения, основанные на других свойствах и параметрах. Это расширяет возможности стилизации и уменьшает необходимость в JavaScript для динамических стилей.

Вложенные правила CSS
CSS Nesting позволяет использовать вложенные правила без необходимости в препроцессорах, упрощая структуру стилей и уменьшая объем кода. Это делает CSS более читаемым и поддерживаемым.

❗️ Новые возможности CSS в 2025 году значительно сократили необходимость использования JavaScript для реализации интерактивных и динамических элементов на веб-страницах, упрощая разработку и улучшая производительность приложений.

Источники
Frontend Wrapped 2025: 10 ключевых событий года.
Анимации без JavaScript — новые возможности CSS 2025.
Заметки о выпуске веб-платформы Microsoft Edge 139 (август 2025 г.).
Фронтенд 2025: AI-революция, Server-First и конец эпохи тяжёлых SPA.

Внутренние процессы браузера при загрузке страницы

Архитектура браузера
Современные браузеры используют многопроцессную архитектуру для повышения стабильности и безопасности. Основные компоненты включают процесс браузера, процессы рендеринга для каждой вкладки, процесс GPU и процессы расширений. Такая структура позволяет изолировать сбои и повышает производительность.

Этапы загрузки страницы
При вводе URL браузер выполняет следующие шаги:
👉 Разрешение доменного имени через DNS для получения IP-адреса сервера.
👉 Установление TCP-соединения с сервером.
👉 Отправка HTTP-запроса и получение ответа.
👉 Парсинг HTML-кода и построение DOM-дерева.
👉 Загрузка и применение CSS для формирования CSSOM.
👉 Объединение DOM и CSSOM в рендер-дерево.
👉 Вычисление геометрии элементов (layout).
👉 Отрисовка элементов на экране (painting).

Гидратация
Гидратация — процесс, при котором клиентский JavaScript делает статически отрендеренную страницу интерактивной, присоединяя обработчики событий к элементам DOM. Это обеспечивает быструю первую отрисовку контента, но требует дополнительного времени для полной интерактивности.

Оптимизация загрузки
Для минимизации времени загрузки страницы рекомендуется:
👉 Использовать асинхронную загрузку скриптов.
👉 Минимизировать количество HTTP-запросов.
👉 Оптимизировать изображения и другие ресурсы.
👉 Использовать кэширование.
👉 Применять Content Delivery Network (CDN) для ускорения доставки контента.

Факты
👉 Многопроцессная архитектура браузеров повышает стабильность и безопасность.
👉 Гидратация делает статически отрендеренные страницы интерактивными.
👉 Оптимизация загрузки включает асинхронную загрузку скриптов и использование CDN.

❗️Понимание внутренних процессов браузера при загрузке страницы позволяет разработчикам оптимизировать производительность и улучшить пользовательский опыт.

Источники
Руководство по работе современного браузера описано в данном источнике.
Этапы отрисовки веб-страницы раскрыты в статье на lexusalex.site.
Описание гидратации можно найти на Википедии.
Советы по оптимизации загрузки доступны на MDN.

Как одна строка CSS может сломать производительность вашего приложения

Введение
Небольшие изменения в CSS могут существенно повлиять на производительность веб-приложения. Одна строка кода способна замедлить загрузку страницы и ухудшить пользовательский опыт.

Сложные селекторы
Использование сложных CSS-селекторов увеличивает нагрузку на браузер при рендеринге страницы. Например, глубокая вложенность или чрезмерно специфичные селекторы усложняют обработку стилей и могут замедлить отображение контента. Рекомендуется упрощать селекторы и избегать избыточной специфичности. Освоение этой практики поможет избежать проблем, таких как общие ошибки в CSS.

Неиспользуемые стили
Загрузка неиспользуемых CSS-правил увеличивает размер страницы и время ее загрузки. Исследования показывают, что средний сайт содержит около 37% неиспользуемого CSS. Это приводит к дополнительной нагрузке на браузер и замедляет рендеринг. Регулярный аудит и удаление неиспользуемых стилей помогают оптимизировать производительность. Подробнее об этом вы можете узнать в статье о скрытых налогах производительности.

Инлайн-стили
Использование инлайн-стилей увеличивает размер HTML-документа и препятствует кэшированию стилей браузером, что замедляет загрузку страниц. Кроме того, инлайн-стили усложняют поддержку и обновление кода. Рекомендуется использовать внешние таблицы стилей для улучшения производительности и удобства сопровождения. Ознакомьтесь с причинами, почему следует избегать инлайн-стилей.

Оптимизация CSS
Для повышения производительности следует минимизировать и объединять CSS-файлы, избегать глубокого вложения селекторов и использовать только необходимые стили. Инструменты, такие как PurgeCSS, помогают выявлять и удалять неиспользуемые CSS-правила, снижая нагрузку на браузер и ускоряя рендеринг страниц. Узнайте больше о решении каскадных проблем в больших проектах из этой статьи.

Факты
👉 Средний сайт содержит около 37% неиспользуемого CSS, что замедляет загрузку страниц.
👉 Сложные селекторы и глубокая вложенность усложняют обработку стилей браузером, замедляя рендеринг.

Итог
❗️ Даже одна строка CSS может существенно повлиять на производительность приложения. Регулярный аудит и оптимизация стилей необходимы для обеспечения быстрой и эффективной работы веб-приложений.

Источники
Освоение сложных CSS-селекторов — Avoiding Common Mistakes in CSS.
Анализ неиспользуемого CSS — The Hidden Performance Tax: How Unused CSS and JavaScript Slow Down Every Page.
Влияние инлайн-стилей — Why You Should Avoid Inline Styles in HTML.
Оптимизация каскадных проблем — Overcoming CSS Cascade Issues in Large Projects.

Отрисовка шрифтов в браузерах

Важность отрисовки шрифтов
В своей практике я часто сталкиваюсь с задачей правильно отобразить типографику на веб-страницах. Это кажется тривиальным, но отрисовка шрифтов — это целая наука, в которой браузеры играют ключевую роль. Мне важно понимать, как браузеры работают со шрифтами, чтобы гарантировать их корректное и согласованное отображение во всех средах. Типографика влияет не только на внешний вид, но и на удобочитаемость и общее восприятие контента.

Процесс отрисовки шрифтов в браузерах
Когда я разрабатываю интерфейсы, я учитываю, что браузеры выполняют несколько этапов, чтобы отрисовать шрифты. Браузер загружает @font-face декларации, определяет доступные шрифты, применяет их к текстовым элементам и в итоге отрисовывает текст на экране. На каждом из этих этапов может возникать ряд проблем, например, флэш безстилевых текстов (FOUT).

Базовый пример использования @font-face

/* Подключение шрифта через @font-face */
@font-face {
  font-family: 'Open Sans';
  src: url('/fonts/OpenSans-Regular.ttf') format('truetype');
  font-weight: normal;
  font-style: normal;
}

Практический сценарий: динамическое подключение шрифтов

/* Использование переменных CSS для изменения шрифта в зависимости от темы */
:root {
  --main-font: 'Open Sans', sans-serif;
}
body {
  font-family: var(--main-font);
}

Факты:
👉 Браузеры используют систему шрифтовой субпиксельной рендеринга для улучшения читаемости.
👉 Некоторые браузеры поддерживают новое свойство font-display для контроля загрузки шрифтов.

❗️Понимание работы шрифтов в браузерах помогает избежать распространённых проблем с отрисовкой и позволяет предложить пользователям лучший опыт взаимодействия с текстом.

TG: Frontender's notes ru

Недавно решил разобраться с фичей skills в Claude Code. Если коротко, это инструмент, который пришел на смену кастомным slash-командам и значительно расширяет их возможности.

В процессе изучения нашел несколько интересных моментов:

- Генерация маркетингового контента:
Анализирует приложение и помогает писать посты для продвижения, например для Хабра.

- Подбор свободных доменов:
Проверяет доступность доменов по теме проекта и предлагает варианты.

- Поиск потенциальных клиентов:
Помогает находить аудиторию, которой может быть интересен ваш продукт. Эту штуку я еще не тестил но звучит как магия.

- Улучшение фронтенда:
Помогает привести сгенерированный нейросетью фронтенд в более аккуратный и продакшен-подобный вид. Так как фронт это мое основное направление то эта штука это то что я протестил чуть больше. Разница в качестве генерируемого кода мне показалась довольно заметной.

Вообще про skills я слышал уже несколько раз, но игнорировал. Для работы мне обычно хватало базовых команд вроде проверки кода. На данный момент я еще продолжаю изучать этот инструмент но уже выглядит как что то довольно интересное.

👉 Геныч.

🧭 Разбираем React вместе с Podlodka React Crew

Современные React-приложения становятся всё сложнее. Разработчики регулярно сталкиваются с проблемами производительности, утечками памяти и архитектурными вызовами.

Базового понимания фреймворка становится недостаточно для результативной работы.

💡Эксперты Podlodka React Crew решили разобраться с этой проблемой на онлайн-конференции под названием «Продвинутый React».

С 23 по 27 марта ее участники:

⚙️ узнают, как устроен рендер и внутренние механизмы в современном React

🧠 познакомятся с архитектурой приложений, где применяются React Server Components

📊 научатся профилировать React-приложения и выявлять медленные рендеры, memory leak

🛠️познакомятся с дополнительными инструментами, которые помогут упростить отладку и выявить сложные проблемы

Формат — удобный и ламповый: пять дней, живые Zoom-сессии утром и вечером, закрытое профессиональное сообщество в Telegram и общение со спикерами.

Если хотите углубить свои знания про React в компании крутых экспертов, присоединяйтесь к Podlodka React Crew👇

🎟Забрать early-bird билет: https://podlodka.io/reactcrew

Почему сложный CSS чаще бьёт по CPU, чем тяжёлый JavaScript

Принято считать, что основная нагрузка во фронтенде — это JavaScript.
Мол, если страница тормозит, значит где-то тяжёлый скрипт.

На практике довольно часто виноват… CSS.

И дело в том, как именно браузер его обрабатывает.

CSS работает постоянно

JavaScript обычно выполняется в конкретный момент:
👉 обработчик события
👉 инициализация
👉 вычисление

Отработал — и всё.

CSS работает иначе.
Он участвует практически в каждом кадре рендера.

Каждый скролл, анимация или изменение DOM может запускать:
👉 перерасчёт стилей
👉 layout
👉 paint

Если CSS сложный — браузер платит за это снова и снова.
Селекторы тоже стоят денег

Например:

.page .content .list li .item .title span

Чтобы применить такой селектор, браузер проходит по DOM
и проверяет цепочку совпадений.

Когда элементов много — таких проверок становится тысячи.

Поэтому правила вроде:
👉 глубоких вложенных селекторов
👉 :not()
👉 :nth-child()
👉 сложных комбинаций

могут неожиданно становиться узким местом.

Layout — один из самых дорогих этапов

Некоторые CSS-свойства заставляют браузер пересчитывать геометрию страницы.

Например:
👉 width
👉 height
👉 top / left
👉 margin
👉 grid
👉 flex

Если такие изменения происходят часто,
браузер запускает reflow.

Reflow — один из самых тяжёлых процессов рендеринга.
Paint может быть ещё дороже

После layout браузер должен всё перерисовать.

Особенно дорогими оказываются:
👉 большие box-shadow
👉 blur
👉 сложные gradients
👉 backdrop-filter

Каждый кадр требует новой отрисовки пикселей.

На слабых устройствах это легко превращается в просадку FPS.

JavaScript можно остановить. CSS — нет

Если JS тяжёлый, его можно:
👉 разбить
👉 мемоизировать
👉 выполнить один раз

CSS же применяется всегда,
пока элемент существует.

Именно поэтому сложные стили иногда оказываются дороже сложной логики.

Главная мысль

Проблемы производительности часто ищут в JavaScript.
Но узкое место нередко оказывается в рендеринге.

Там, где:
👉 сложные селекторы
👉 дорогие эффекты
👉 частые layout-пересчёты

Секунда уверенности → полгода страданий

Нужны твои навыки в работе с ИИ на МТС True Tech Hack 2026!

Тебе сюда, если ты инженер данных, разработчик или системный аналитик. 1 500 000 рублей — общий призовой фонд ИТ-соревнования.

Формат: командное онлайн-соревнование с финалом в Москве. Если нет команды — поможем найти на платформе мероприятия.

Тебя ждут три задачи на выбор — каждая с уникальной технической фишкой.

Для всех финалистов — приглашение на закрытую вечеринку, а лучших участников позовут на стажировку.

Успей зарегистрироваться до 9 апреля

Браузерный GC и почему утечки на фронте сложнее, чем кажется

Есть ощущение, что в браузере всё безопасно.
GC же есть — значит память сама почистится.

На практике утечки на фронте происходят регулярно.
И часто их сложнее поймать, чем на бэкенде.

GC не «чистит всё подряд»

Сборщик мусора удаляет только то,
на что больше нет ссылок.

Если объект всё ещё достижим —
он остаётся в памяти.

Даже если он тебе уже не нужен.
Где обычно начинаются утечки

Замыкания

function createHandler() {
const bigData = new Array(1000000).fill('data')

return () => console.log(bigData.length)
}
Пока существует функция — живёт и bigData.

События

element.addEventListener('click', handler)

Если не удалить listener —
ссылка на handler остаётся,
а вместе с ней и всё, что он замкнул.

Таймеры

setInterval(() => {
doSomething()
}, 1000)

Забыли очистить — получили вечную ссылку.

Глобальные кэши

const cache = {}

Если кэш растёт без контроля —
GC тут не поможет.

Почему на фронте сложнее

Долгоживущая сессия

Пользователь может не обновлять страницу часами.
Утечка не проявляется сразу — она накапливается.

Сложные связи
DOM, события, состояние, сторонние библиотеки.
Объекты держат друг друга,
и понять цепочку ссылок непросто.

«Работает же»
Пока не начались лаги и фризы,
никто не думает про память.

Частая ловушка

Удалили DOM-элемент — и кажется, что всё ок.

Но если на него всё ещё есть ссылка:
👉 в listener
👉 в замыкании
👉 в кеше

Он остаётся в памяти.
Как с этим жить

👉 всегда чистить listeners
👉 контролировать таймеры
👉 не держать лишние ссылки
👉 ограничивать кэши
👉 проверять heap snapshots в DevTools