Горячий код в V8

Настя Котова у себя в телеграм-канале продолжает разбираться в глубинах Node.js и V8. В этот раз задалась интересным вопросом: что же такое «горячий код» для V8? Один и тот же код может превращаться в итоге в разные инструкции внутри движка, причём скорость выполнения этих инструкций тоже может значительно отличаться. Потому что на старте он «холодный», а чем больше движок собирает статистики про выполнение, тем лучше может его оптимизировать.

В этом полезно разбираться:
• если вы пишете бенчмарки и удивляетесь, почему они каждый раз выдают разные результаты;
• ваш проект дошёл до стадии оптимизации производительности на уровне подстраивания под движок (может быть важно на высоконагруженных проектах);
• при работе с облачными функциями (вопрос денежки);
• для общего развития.

https://telegra.ph/Goryachij-kod-v-V8-chto-ehto-znachit-04-05

Много маленьких страниц

Джим Нильсен делится интересной идеей под названием LLMs — (L)ots of (L)ittle ht(M)l page(S). Суть в том, чтобы почти не использовать JS, отказаться от SPA, а каждый экран сделать маленькой страницей. Да, каждая модалка или таблица с фильтром — отдельная страница.

В статье разбирается паттерн меню. Кликаешь на бургер — открывается страница с меню. Жмёшь на крестик — тут уже JS делает history.back(), небольшое читерство.

Сначала ощущается такой подход странно. Крайне непривычно. Но спустя какое-то время мне идея всё-таки приглянулась.

Всё упирается в то, чтобы изначально UX продумать так, чтобы каждое действие и было отдельным экраном. Если присыпать это всё CSS View Transitions, сделать лёгкие кэшируемые страницы только с необходимым, то работать ведь будет быстро. Добавим сюда сервис-воркеры и Speculation Rules API — можно добиться ощущения мгновенности. Для статических сайтов — ну очень хорошо.

https://blog.jim-nielsen.com/2026/small-html-pages/

История ffmpeg

Видео невыходного дня. Интересный ресёрч на тему того, как небольшая опенсорс библиотека стала основой для огромного числа других проектов. И какие люди за этим стоят. Если что, вы пользуетесь ffmpeg каждый день, даже если не знаете про это.

https://youtu.be/Ww8MzcBJUd4

Анимированный фокус на View Transitions

Думаю, вы видели такой паттерн, когда кольцо фокуса (обводка, которая рисуется вокруг сфокусированных элементов интерфейса) перемещается по странице плавно, с анимацией. Не резко перескакивает, как это делает браузер, а аккуратно перетекает. Для такого часто используются JS-библиотеки, которые играют в «угадай координату» и двигают по сути абсолютно спозиционированный элемент по странице.

Крис Койер пробует сделать версию попроще. Пускай во время перехода фокуса включается View Transition: включаем новое кольцо на новом элементе, старое выключаем, запускаем анимацию. Звучит интересно, и кода требует прям мало.

К сожалению, сделать хорошо не получилось:
• Во-первых, в единственном более-менее рабочем решении пришлось расставить дочерний span в каждом интерактивном элементе. А хотелось бы вёрстку не править.
• Во-вторых, управление фокусом идёт на уровне JS, а это уже риски что-то не учесть (браузер умеет это лучше, не пытайтесь его имитировать).
• В-третьих, если текст ссылки содержит перенос (то есть находится на двух строках сразу), то визуально всё неприлично разломано.

В комментариях к статье приложили демку с решением на Anchor Positioning. Там проблемы похожие, хотя лишний span уже не нужен, и это радует.

В общем, присмотреться к способу двигать что-то анимированно по странице новыми апишками точно стоит. А вот применять такое к фокусу — лучше не надо, рендеринг текста сложнее, чем просто коробочка с буквами. К сожалению, тут я скорее за то, чтобы использовать JS-библиотеки, проверенные временем.

https://frontendmasters.com/blog/animating-focus-with-view-transitions/

От React к нативному вебу с nanotags

Отличное применение принципа «под каждую задачу — правильный инструмент».

Павел Гринченко на примере показывает, что для лендинга или маркетингового сайта не обязательно тащить увесистые фреймворки, которые придуманы для тяжёлых SPA с развесистой бизнес-логикой. Но да, для этого придётся разобраться в «новых» технологиях.

https://t.me/webstandards_ru/7729

Chrome DevTools MCP CLI

Поигрался на выходных с Chrome DevTools MCP CLI — и мне понравилось.

Джоан Леон в статье рассказывает, что умеет инструмент. И показывает, как его можно подружить с различными полезными JS-сниппетами на примере WebPerf.

У меня был простой эксперимент: попросить LLM сделать аудит страницы, предложить улучшения по Core Web Vitals. Сначала без установки новой тулзы LLM использовала Playwright, Lighthouse, что-то покрутила, выдала результаты аудита. Затем с chrome-devtools-mcp повторила то же самое — аудит был куда подробнее и предложения более интересные.

Судя по логам, преимущество chrome-devtools-mcp в том, что он активно использует всевозможные Insights из Chrome DevTools. Playwright из-за своей универсальности не всем может поделиться. По токенам, кстати, вышло примерно одно и то же.

В общем, для задач, когда нужно на скорую руку сделать аудит страницы, chrome-devtools-mcp зашёл на ура. Оптимизировать, правда, я пока доверяю только своим мозгам — LLM-ки всё ещё творят какую-то дичь, когда дело касается современных API.

https://joanleon.dev/en/chrome-devtools-mcp-cli/

Сжатие и растяжение

Джош Комо с очередным классным гайдом с демками. На этот раз — про анимации трансформации.

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

В демках в статье показывается, как такое можно сделать на SVG+CSS либо при помощи JS-библиотеки Motion. В обоих случаях получается вау-эффект.

https://www.joshwcomeau.com/animation/squash-and-stretch/

Объединение мобильного и десктопного доменов

Тимо Тийхоф из MediaWiki (движок для Википедии) поделился интересным опытом объединения доменов [lang].wikipedia.org и [lang].m.wikipedia.org.

Когда-то давно было популярной практикой разделять мобильную версию и десктопную отдельными поддоменами. Мобильные телефоны были слабее, мобильный интернет был медленным, а про адаптивность ещё почти не говорили. Google-поиск эту историю поддерживал, автоматически выдавая верный поддомен в зависимости от того, с какого устройства пользователь искал.

В 2016 году Google изменил политику касательно отдельных мобильных версий, теперь правильнее делать единый домен, причём по принципу Mobile First. Раскатка была долгой, до Википедии дошли только в 2024 году.

Тимо рассказывает, как необходимость объединить домены повлияла на скорость загрузки, SEO и нагрузку на инфраструктуру.

https://techblog.wikimedia.org/2025/11/21/unifying-mobile-and-desktop-domains/

Оптимизация сайта для AI-ответов в Google-поиске

Гайд от Google по тому, что делать и что не делать, чтобы генеративный AI в выдаче поиска работал лучше.

Итак, пункты:
• Создавать полезный людям контент.
• Уникальность контента, своя точка зрения.
• Понятность текста.
• Качественные картинки и видео для визуализаций.
• Фокус на том, что хотят пользователи.
• Страницы должны не мешать краулерам их парсить.

То есть буквально ничего нового делать не нужно. Просто делаешь хороший и удобный сайт для пользователей — и внезапно он в попадает в AI-ответы. Только прикол в том, что если раньше нужно было как-то умудриться попасть в топ-10 поиска по целевым запросам, то теперь нужно попасть в топ-5 по смыслу запроса пользователя — конкуренция выросла.

Есть ещё раздел с разрушением мифов, он забавный. Например, LLMS.txt краулеру не нужен, он до этого десятилетиями как-то справлялся без отдельной версии под себя и норм.

Рекомендуют делать ставку на то, чтобы сайт был удобен агентам. Тут нужно дождаться Google I/O с их анонсами агентских фичей браузера, гуглбуков и прочих рекомендаций, как подстраивать свой бизнес под фичи одной конкретной корпорации.

https://developers.google.com/search/docs/fundamentals/ai-optimization-guide

What's new in Web UI

Заходите смотреть Google I/O, там через 3 минуты будут показывать новые браузерные фичи, которыми нам с вами потом пользоваться. Как бы мы в подкасте периодически не ругали Chrome за торопливость, на веб-индустрию они влияют значительно.

https://www.youtube.com/live/OQK9XHTiqVw

Улучшаем браузерное кэширование заголовком No-Vary-Search

Итак, вы оптимизировали браузерный перфоманс своего сайта. Но когда маркетологи запускают вокруг сайта разные акции, на мониторингах почему-то проседают метрики.

Дело в том, что в таких случаях часто к урлам дописывают что-то вроде ?utm_source=google. Для сбора метрик и конверсий. Такие параметры для браузера обозначают, что это абсолютно новая страница, её нельзя брать из кэша. Браузер ведь не знает, для метрики оно или для обработки на сервере и изменения контента.

Гарри Робертс рассказывает про заголовок No-Vary-Search, который решает эту проблему. Можно попросить браузер игнорировать конкретные параметры, все параметры или их порядок, чтобы брать страницу из кэша.

https://csswizardry.com/2026/05/better-browser-caching-with-no-vary-search/