Веб-страница - фронтенд бэкенд девопс

Cloudflare автоматизировала обмен ключами с серверами сайтов Cloudflare включила Automatic Key Exchange по умолчанию для доменов. Функция касается защищённого соединения между прокси Cloudflare и сайтом. Раньше Cloudflare начинала обмен по TLS 1.3 с X25519; при другом выборе сервера повтор добавлял полный сетевой круг. Теперь сервис ежедневно проверяет серверы отдельно от рабочего трафика и первой предлагает сильнейший поддерживаемый алгоритм, прежде всего постквантовый X25519MLKEM768. Изменение развёртывают на части трафика и отменяют, если число повторов растёт. При развёртывании доля повторов снизилась примерно с 52% до 3,7%, а задержка на 90-м процентиле сократилась более чем на 150 мс. Сотни тысяч доменов получили постквантовые соединения без ручной настройки. Разбор Cloudflare пригодится тем, кто отвечает за TLS: в панели можно проверить режим и ограничения по стандартам.

Как кэшировать HTML, CSS и JavaScript без рассинхронизации Короткий max-age для изменяемых файлов выглядит компромиссом. Но браузер может оставить старые HTML и JavaScript, удалить CSS из кэша и запросить его заново. Если сервер уже отдаёт новые стили, страница соберётся из несовместимых версий. В тестах это легко пропустить. Для неизменяемой статики надёжнее менять URL вместе с содержимым, например добавлять хеш, и задавать max-age=31536000. Для HTML подходит no-cache: браузер хранит ответ, но перед использованием сверяет его с сервером через ETag или Last-Modified. Название меткое: кэшировать оно как раз разрешает. Подробный разбор кэширования пригодится перед настройкой заголовков и service worker. Проверьте, не получают ли изменяемые файлы короткий max-age, а для статики версионируйте URL.

Почему CORS устроен именно так и как с ним работать CORS проще отлаживать, если начать не с заголовков ответа, а с границы, которую охраняет браузер. Страница может загрузить картинку, скрипт или стиль с другого источника, но её код не может прочитать DOM чужой страницы или тело ответа. Источник здесь — сочетание схемы, хоста и порта. Даже если не отправлять cookie, этого недостаточно. Внутренние панели, роутеры и устройства умного дома могут считать защитой саму локальную сеть, поэтому сервер должен явно разрешить чужой странице читать ответ. Я сохранил разбор CORS с интерактивной песочницей как карту для отладки трёх слоёв: источников, учётных данных и разрешения сервера.

Как браузер рисует кадры и где теряется плавность Экран с частотой 60 Гц обновляется каждые 16,66 мс. С учётом работы браузера нужно уложиться в 10 мс: иначе частота кадров падает, а движение начинает дёргаться. В разборе web.dev путь визуального изменения разделён на расчёт стилей и геометрии, отрисовку пикселей и сборку слоёв. Свойства width, height, left и top заставляют браузер пройти все эти этапы. Для цвета, фонового изображения или тени пересчёт геометрии не нужен. Если свойство не требует и новой отрисовки, браузер сразу собирает готовые слои. Если анимация дёргается, проверьте в DevTools, какие этапы запускают её CSS-свойства. Начните с тех, что меняют размеры и положение: сокращение лишней работы освобождает время внутри кадра.

Как INP измеряет отзывчивость веб-страницы INP, задержка до следующей отрисовки, показывает время от клика, касания или нажатия клавиши до визуального ответа браузера. Оно складывается из ожидания обработчиков, выполнения их кода и подготовки кадра. Обычно в итог попадает самое медленное действие за визит. Ориентир считают по 75-му процентилю отдельно для мобильных и настольных устройств: до 200 мс включительно считается хорошим результатом, свыше 200 и до 500 мс требует улучшения, свыше 500 мс означает плохую отзывчивость. Начните с PageSpeed Insights: данные CrUX покажут оценку по реальным визитам. Затем RUM, мониторинг реальных пользователей, поможет найти медленное действие, а лабораторный тест позволит его воспроизвести. В разборе INP на web.dev объясняют, почему метрика иногда отсутствует и чем ограничены лабораторные измерения.

Как stale-while-revalidate отдаёт кэш сразу и обновляет его в фоне Директива stale-while-revalidate в заголовке Cache-Control разрешает браузеру показать устаревшую копию без ожидания сети. Одновременно браузер запрашивает свежий ответ и сохраняет его для следующего обращения. На примере max-age=1, stale-while-revalidate=59 механика видна по секундам: первую секунду ответ считается свежим; следующие 59 секунд браузер сразу отдаёт копию и обновляет её в фоне; позже уже ждёт сеть. Такой режим подходит данным, которые запрашивают часто и обновляют по известному расписанию, например погоде или заголовкам новостей. Я сохранил разбор web.dev как шпаргалку для настройки API: он помогает выбрать интервалы кэширования и заранее решить, насколько устаревший ответ допустим для пользователя.

Как content-visibility ускоряет отрисовку длинных страниц Если на странице десятки карточек, браузеру необязательно сразу рассчитывать стили и раскладку для всего списка. С content-visibility: auto он пропускает отрисовку содержимого секций за пределами экрана и выполняет её, когда секция приближается к области просмотра. В примере с блогом время отрисовки сократилось с 232 до 30 мс. Есть цена: без заданного размера пропущенная секция считается пустой, поэтому полоса прокрутки может прыгать. contain-intrinsic-size задаёт размер-заполнитель, а значение auto позволяет затем запомнить фактический размер. Откройте разбор на web.dev перед оптимизацией ленты или SPA: там показаны CSS-код, ограничения доступности и отличие от display: none и visibility: hidden.

Почему гидрация React ломается при разном HTML на сервере и в браузере При серверном рендеринге React отдаёт готовый HTML. Затем браузер гидрирует его: связывает DOM-узлы с компонентами. В этот момент React ожидает ту же структуру, что сформировал сервер, а не ищет и исправляет различия. Поэтому проверка typeof window внутри рендера опасна. Если на сервере компонент возвращает null, а в браузере сразу добавляет навигацию, структуры HTML расходятся. Иногда React справляется, но гидрация оптимизирована ради скорости, и элементы могут оказаться не на своих местах. Если интерфейс верен в разработке, но ломается после сборки, а React DevTools показывает правильное дерево, разбор Джоша У. Комо поможет сверить первый клиентский рендер с готовым HTML и проверить структуру DOM.

Почему React перерисовывает компоненты и как остановить каскад Изменение состояния запускает повторный рендер компонента-владельца и его потомков. Даже если дочерний компонент не получает изменившийся count через пропсы, React выполняет его код снова: косвенную зависимость исключить нельзя. Поэтому лишние рендеры стоит искать от владельца состояния вниз по дереву, а React DevTools использовать, чтобы увидеть причину повторной отрисовки конкретного компонента. Если чистый потомок при одинаковых пропсах возвращает тот же интерфейс, React.memo позволяет взять предыдущий результат. В разборе Why React Re-Renders на сайте Josh W. Comeau это показано на интерактивных схемах и примерах с Counter, BigCountNumber и Decoration.