#инструмент дня

Вы, конечно, все в курсе, что порядок подключения ресурсов сильно влияет на скорость отображения страницы, на TTI — время от начала загрузки до возможности работы со страницей. Но как конкретно? Как точно выяснить, в каком порядке и что загружать?

И вот тут нам поможет сниппет для DevTools под названием Capo.js: https://github.com/rviscomi/capo.js

Порядок применения:
1. Берёте capo.js, значит
2. Солите его блять Загружаете как сниппет в девтулзы: https://developer.chrome.com/docs/devtools/javascript/snippets/
4. ...
5. Наблюдаете диаграмму в консоли! Она отобразит текущее и желаемое положение вещей.

А кому охота подробностей, тому вот сюда, на эту презентацию Виталия Фридмана: https://youtu.be/uqLl-Yew2o8

#css #js #performance

#инструмент дня

Пожалуй, только лишь карась на дне не слышал аббревиатур LCP, TTFB, BPP, CLS и так далее. Что их всех объединяет?

А это все метрики производительности веб-проектов. Если вы запускали тот же самый Lighthouse, то наверняка знаете, что на получение 100% влияет очень и очень многое. Так вот.

Сегодняшний инструмент дня это набор сниппетов для Chrome DevTools для визуализации и считывания влияющих на параметры производительности показателей:
https://webperf-snippets.nucliweb.net/

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

И, например, имеется код для анализа скорости подгрузки сторонних скриптов и их влияния на ваш сайт.

Прекрасная штука, в общем.

#performance #devtools

#видео дня

Вы спорили об этом всю свою карьеру. Делали предположения, правильные и не очень. А потом появились is, has, контейнерные запросы, слои... И всё заново.

О чём это я? Конечно же о производительности селекторов CSS!

Насколько быстр начальный рендер? Насколько замедляется перерисовка экрана при использовании новомодных фишек CSS? На все эти вопросы ответить можно только... только читая исходники браузерных движков. Вам не лень? Мне — точно.

А вот Патрику Броссе вот было не лень. И на недавно прошедшем CSS DAY он выступил с докладом, который так и называется: Style Recalculation Secrets They Don’t Want You To Know

Собственно, ссылочка: https://www.youtube.com/watch?v=WRiOWJZoKlw

А для самых внимательных — в имени ссылка на слайды.

Вышло офигенски залипательно, рекомендую всем.

#css #performance

#статья дня

Один из самых популярных вопросов на собеседовании, это мемоизация.

Естественно, чаще всего вопрос задаётся в контексте React. Ну уж так повелось почему-то, хотя тема гораздо обширнее.

Три столпа мемоизации в React это React.memo и хуки useMemo и useCallback. Ну и вопрос в том, а стоят ли они того?

Как правило ответы стандартные: мы проигрываем в памяти и процессоре при инициализации, но выигрываем в повторном обращении. И дальше прочее веселье с тем, а как посчитать performance impact и так далее.

А вот парни из Coinbase решили, что не надо считать. А надо сразу оборачивать всё, что угодно, в memo, мол, влияние на инициализацию минимальное, а тратить время на предварительные расчёты неохота.

Ну что же, им слово тогда: https://attardi.org/why-we-memo-all-the-things/

Статья небольшая, выводы стоят рассмотрения.

P. S. как вам новое превью к постам, котаны? Думаю, сверстать его для автоматизации и выложить таймлапс или сделать стрим или типа того...

#react #memo #performance

#статья дня

Что больше всего бесит в рекламе на сайтах? Почему каждый второй ставит адблоки и прочие ублоки?

Ну, как минимум, назойливость. Во всяком случае, это то, что бесит лично меня. Вторая причина — количество баннеров.

Тем не менее, без рекламы бесплатный веб практически невозможен. Да, кто-то особо гордый скажет: "Я зарабатываю деньги в реальном мире, а не в интернете", но мы его и не спрашивали.

Так, вся эта сопливая подводка к чему, в блоге Google Chrome вышла хорошая статья на тему оптимизации рекламных вставок. Встречайте: https://web.dev/articles/loading-ads-page-speed

Как и в каком порядке размещать баннеры и контент, когда применять и не применять ленивую загрузку, как обновлять вставки. По пути немного про LCP, CLS и асинхронную загрузку.

Если вас в принципе тошнит от самой мысли о рекламе, воспринимайте статью как практическое руководство по производительности сайтов и приложений. Полезно.

#ad #lcp #cls #performance

#статья дня

Что больше всего бесит в рекламе на сайтах? Почему каждый второй ставит адблоки и прочие ублоки?

Ну, как минимум, назойливость. Во всяком случае, это то, что бесит лично меня. Вторая причина — количество баннеров.

Тем не менее, без рекламы бесплатный веб практически невозможен. Да, кто-то особо гордый скажет: "Я зарабатываю деньги в реальном мире, а не в интернете", но мы его и не спрашивали.

Так, вся эта сопливая подводка к чему, в блоге Google Chrome вышла хорошая статья на тему оптимизации рекламных вставок. Встречайте: https://web.dev/articles/loading-ads-page-speed

Как и в каком порядке размещать баннеры и контент, когда применять и не применять ленивую загрузку, как обновлять вставки. По пути немного про LCP, CLS и асинхронную загрузку.

Если вас в принципе тошнит от самой мысли о рекламе, воспринимайте статью как практическое руководство по производительности сайтов и приложений. Полезно.

#ad #lcp #cls #performance #бородач

#инструмент дня

Пожалуй, только лишь карась на дне не слышал аббревиатур LCP, TTFB, BPP, CLS и так далее. Что их всех объединяет?

А это все метрики производительности веб-проектов. Если вы запускали тот же самый Lighthouse, то наверняка знаете, что на получение 100% влияет очень и очень многое. Так вот.

Сегодняшний инструмент дня это набор сниппетов для Chrome DevTools для визуализации и считывания влияющих на параметры производительности показателей:
https://webperf-snippets.nucliweb.net/

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

И, например, имеется код для анализа скорости подгрузки сторонних скриптов и их влияния на ваш сайт.

Прекрасная штука, в общем.

#performance #devtools #бородач

#инструмент дня

Вы, конечно, все в курсе, что порядок подключения ресурсов сильно влияет на скорость отображения страницы, на TTI — время от начала загрузки до возможности работы со страницей. Но как конкретно? Как точно выяснить, в каком порядке и что загружать?

И вот тут нам поможет сниппет для DevTools под названием Capo.js: https://github.com/rviscomi/capo.js

Порядок применения:
1. Берёте capo.js, значит
2. Солите его блять Загружаете как сниппет в девтулзы: https://developer.chrome.com/docs/devtools/javascript/snippets/
4. ...
5. Наблюдаете диаграмму в консоли! Она отобразит текущее и желаемое положение вещей.

А кому охота подробностей, тому вот сюда, на эту презентацию Виталия Фридмана: https://youtu.be/uqLl-Yew2o8

#css #js #performance #бородач

#фишка дня

Кому ещё не надоели споры, что быстрее, # или ., * или :has — те будут рады новой фишке Chrome DevTools в Chrome 125 — Selector Stats!

Кстати, её сделали разработчики Edge, они много внимания уделяют развитию DevTools вообще. Ну что же, у каждого свой PR :)

Впрочем, тем, кому эти споры надоели, можно лишний раз напомнить: CSS вряд ли станет бутылочным горлышком. Ну разве что новые селекторы, has, is, not и злое использование .foo > * и то это надо постараться.

#devtools #chrome #performance

#статья дня

Насколько глубокая вложенность элементов влияет на производительность вашего проекта и влияет ли вообше?

Вот Google Lighthouse утверждает, что влияет. Но так ли это на самом деле?

Коннор проверит

Как хорошо, что у нас теперь есть на это ответ: https://frontendatscale.com/blog/how-deep-is-your-dom/

TL;DR:

1. Ощутимая разница начинается на 500 элементах: плоский список рендерится в два раза быстрее вложенного.
2. Далее расхождение растёт практически линейно и на 5000 элементах мы уже наблюдаем 800 мс для вложенного против 180 мс для плоского. Впрочем, это вырожденный случай.
3. И всё бы ничего, но до этого момента всё обсуждение велось для скелета без стилей, точнее, со встроенными браузерными. Набрасываем ещё немного CSS — и к этой прелесть добавляется 150 мс. Что уже может быть совсем заметно глазу.

Вместо вывода:

Да, 5000 вложенных элементов это редкость, но многие дизайн-системы и UI-киты построены вокруг максимально простой структуры Stack-Row-Col-Element, заставляющей вас создавать лишнюю вложенность. Таких комбинаций на странице могут быть тысячи.

Сама по себе вложенность не является чем-то плохим, но она задаёт базу для пересчёта стилей и JS-операций над DOM, поэтому иногда на это стоит обратить внимание.

#render #performance

#инструмент дня

Вы, конечно, все в курсе, что порядок подключения ресурсов сильно влияет на скорость отображения страницы, на TTI — время от начала загрузки до возможности работы со страницей. Но как конкретно? Как точно выяснить, в каком порядке и что загружать?

И вот тут нам поможет сниппет для DevTools под названием Capo.js: https://github.com/rviscomi/capo.js

Порядок применения:
1. Берёте capo.js, значит
2. Солите его блять Загружаете как сниппет в девтулзы: https://developer.chrome.com/docs/devtools/javascript/snippets/
4. ...
5. Наблюдаете диаграмму в консоли! Она отобразит текущее и желаемое положение вещей.

А кому охота подробностей, тому вот сюда, на эту презентацию Виталия Фридмана: https://youtu.be/uqLl-Yew2o8

#css #js #performance #бородач

#статья дня

Даже две!

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

Конечно, сама ситуация довольно странная, и выглядит так: если у вас имеется замыкание, в котором вы обратились к некоему объекту, после выполнения функции в замыкании выделенная память не очистится. Вот: https://jakearchibald.com/2024/garbage-collection-and-closures/

То есть у нас не утечка памяти, но «захват и удержание»:

function demo() {
  const bigArrayBuffer = new ArrayBuffer(100_000_000)
  const id = setTimeout(() => {
    console.log(bigArrayBuffer.byteLength)
  }, 1000)

  return () => clearTimeout(id)
}

globalThis.cancelDemo = demo();      

В случае, когда у нас нет возвращаемой функции отмены — замыкания не создаётся и сборщик мусора отлично работает.

Так вот, Нико Прананта нашёл решение для данного конкретного случая! И решение это потрясающее: нужно оставить ссылку на буфер за пределами замыкания: https://www.nico.fyi/blog/memory-issue-in-javascript-and-closures

А как это сделать?

Передать буфер следующим аргументом в setTimeout!

function demo() {
  const bigArrayBuffer = new ArrayBuffer(100_000_000)
  const id = setTimeout(
    (buffer) => {
      console.log(buffer.byteLength)
    },
    1000,
    bigArrayBuffer
  )

  return () => clearTimeout(id)
}

globalThis.cancelDemo = demo()

Я рекомендую пробежаться по обеим статьям, но статья Нико содержит в себе ещё и описание методов отладки таких случаев, что может пригодиться.

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

#js #memory #performance

#инструмент дня

Разработчики браузеров, даже те, что пишут на движке Blink от Chrome, очень хотят, чтобы их работу заметили на их продукт в итоге обратили внимание. И достигают они этого разными способами.

Arc активно переосмысляет интерфейс, Vivaldi играет на чувстве ностальгии, Яндекс.Браузер предлагает закладки перевод и озвучание видео в реальном времени, Opera — встраивает VPN.

А ребята из Microsoft Edge — дорабатывают девтулзы. Почти всё новое из последних релизов Chrome — от них.

И вот чтобы покончить все споры на тему производительности CSS, ещё в Chrome 125 бэкпортнули статистику селекторов на вкладке оценки производительности.

Речь там, как правило, о микросекундах в худшем случае, но вдруг...

И, пользуясь случаем, хочу напомнить о замечательном ресурсе Can I DevTools, где можно найти разные фишки работы со средствами разработчика: https://www.canidev.tools/find-expensive-selectors/edge

#css #performance #devtools

#заметка дня

Сегодня немного о том, как же хорошо иметь отклик аудитории в соцсетях.

Некто Бен Дикен (ну как, некто, его статью по B-деревьям и индексам в базах данных мы недавно читали) решил хайпануть на теме производительности разных языков и сред. Ну, на синтетических тестах, если уж совсем точно.

И выкатил видео, на котором тупо визуализировал результат выполнения 1 миллиарда итераций вложенных циклов: https://benjdd.com/loops/

Ну, условно, вот такой код:

let array = new Array(10000);
for (let i = 0; i < 10000; i++) {
  for (let j = 0; j < 100000; j++) {
    array[i] = array[i] + j;
  }
}

Если коротко, то получилось, что JS в Node.js в 30 раз медленнее, чем C, скомпилированный в gcc с -O1 (минимальной оптимизацией).

Ох, как же его начали макать... Опустим очевидные моменты вроде тех, что никому в реальной жизни не интересно, как там миллиард циклов выполнится. Что гораздо интереснее — это как всё улучшить.

Как оказалось, улучшать есть что! На иллюстрации к посту вы видите результат коллективной работы большого числа людей. Как видим, JS лишь в 2-2.5 раза медленнее: https://benjdd.com/languages/

Как так вышло? Очень просто: know your tools.

Например, прям из простейшего: если в JS создать массив как new Array(10000), он будет заполнен мусором и готов будет принимать в себя любые типы элементов. А если new Array(10000).fill(0) — движок оптимизирует код под работу с целыми числами. И буст будет просто огромный.

Вот вам и динамический язык, кто бы мог подумать. Дальше — больше (new Int32Array(10000), например).

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

Особенно если вы собираетесь вложенные циклы миллиардами итераций выполнять.

#performance #test

#ссылка дня

Очень коротенькое дополнение в коллекцию адвент-календарей, которую мы собрали вчера: https://xn--r1a.website/htmlshit/3317

Правда, на сей раз без задачек :)

Календарь статей по производительности веба!

Web Performance Calendar: https://calendar.perfplanet.com/2024/

Каждый день на протяжении декабря будет появляться по статье, посвящённой тому или иному аспекту производительности.

Темой первого декабря был Закон Гудхарта: «Когда мера становится целью, она перестает быть хорошей мерой», очень хорошая вводная статья о том, что не надо бездумно гнаться за показателями.

Темой вчера стал общий обзор терминов.

А сегодня — а пока не знаю, ждём открытия окошка!

#advent #calendar #webperf #performance

#инструмент дня

На связи Глеб, который принес немножечко странного.

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

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

Оказывается не так уж это сложно если вспомнить про алгоритмы сжатия.
Сериализуем объект, сжимаем его с помощью библиотеки lz-string и генерируем ссылку с параметрами состояния редактора в одном из параметров.
Попробовать можно в codepen.

Да, можно использовать более эффективный алгоритм LZMA (один из примеров), однако он существенно медленнее. Тем не менее, производительность LZMA в контексте ограниченного числа символов, позволяет вообще не думать о каком-либо существенном влиянии на результат.

В CedrusData (компания, в которой работаю) много интересных задач, в том числе связанных с производительностью. Ждите новых заметок😎

#compression #performance

#статья дня

Страница грузится 7 секунд.
Причина — один эмодзи ❤️

Иногда проблемы с производительностью оказываются совсем не там, где их ищешь. В статье Аллена Пайка «A Broken Heart» он разбирает случай, когда страница внезапно начала грузиться по 7 секунд, хотя сервер, сеть и JavaScript работали нормально. В профайлере оказалось, что почти всё время Safari тратит на layout — причём один проход занимал больше секунды.

Дальше — обычный путь: постепенно вырезать куски интерфейса и смотреть, когда станет быстрее. В какой-то момент выяснилось, что всё упирается в один эмодзи в кнопке. Убираешь его — всё работает мгновенно. Возвращаешь — снова тормоза.

Причина оказалась в том, как Safari работает со шрифтами. Если указать Noto Color Emoji как основной шрифт, он используется даже для обычного текста, хотя покрывает только эмодзи. Для всех остальных символов браузер каждый раз ищет подходящий fallback-шрифт. В процессе layout он пересчитывает размеры текста, переносы строк и позиции элементов, и делает это много раз подряд.

В норме такие пересчёты почти ничего не стоят, но в Safari здесь есть просадка, из-за которой всё резко замедляется. В итоге одна строка с emoji-шрифтом может увеличить время layout в десятки или даже сотни раз.

Минимальный пример:

<link href="https://fonts.googleapis.com/css2?family=Noto+Color+Emoji" rel="stylesheet">

<style>
  body {
    font-family: "Noto Color Emoji";
  }
</style>

<button>Click ❤️</button>

Если не ставить emoji-шрифт основным, а оставить его только в конце списка как fallback, проблема исчезает. В оригинальной статье есть ещё детали про поиск причины и минимизацию примера — стоит почитать: https://allenpike.com/2026/a-broken-heart/

Ну и официальный issue: https://bugs.webkit.org/show_bug.cgi?id=305636

Потрясающая хрень, конечно. На пустом месте.

#css #emoji #svg #performance

#заметка дня

Вчера сайт 35mmc уронил Chrome на моём iPhone. Я просто читал статью про Olympus XA.

Подключил телефон к Web Inspector, записал таймлайн. За двенадцать секунд страница разогналась до 627 МБ памяти. Процессор жрал до 160%. Safari несколько раз запускал полный сборщик мусора, память немного проседала — и тут же начинала расти снова. Потом вкладка умерла. Буквально Web Page Crashed.

Вы же в курсе, что все браузеры на iPhone — это Safari? Но вот отработка нештатных ситуаций ведёт себя по разному. Chrome просто падает, а Safari — перезагрузит страницу несколько раз, на что-то надеясь.

Кстати, такая тактика даже лучше.

Самое смешное, что перед этим сайт предлагает купить ad-free experience.

Я не против рекламы и не против подписок. Маленькому изданию надо как-то зарабатывать. Но в данном случае выглядит издевательски: «заплатите, чтобы убрать рекламу, пока браузер не упал».

Погонял страницу ещё через Chrome с сетевыми трейсами и heap snapshots. Там не один неудачный баннер, а вполне себе рекламный комбайн: Flashtalking с креативами Adobe, Google SafeFrames, куча bidder’ов и измерителей, плюс Primis video player. А у видео внутри HLS, Google IMA, OMID, video Prebid и ещё свой трекинг.

В прогонах, где включался этот видеостек, память за короткую загрузку и прокрутку прибавляла 8–12 МБ. В других прогонах почти не росла. То есть один читатель получит просто перегруженную страницу, а другому случайно выпадет набор рекламы, который положит вкладку.

Не буду делать вид, что по одному таймлайну можно назвать виновника каждого байта. Но когда GC работает, память всё равно растёт, а Safari убивает процесс — пользователю всё равно, как это правильно назвать: memory leak, allocation pressure или «interplay независимых рекламных систем».

Он просто не дочитает статью.

#performance

#заметка дня

В конце прошлого года в Chrome появилась небольшая, но полезная оптимизация CSS-анимаций. Браузер перестал считать любое упоминание width или height безусловной причиной выполнять анимацию на в основном потоке.

Раньше даже такой код лишал opacity возможности анимироваться на compositor:

@keyframes fade {
from {
width: 200px;
opacity: 0;
}

to {
width: 200px;
opacity: 1;
}
}

Ширина здесь вообще не меняется, но одного присутствия width в keyframes было достаточно, чтобы Chrome счёл всю анимацию non-composited.

В Chrome 144 это исправили. Blink теперь проверяет, действительно ли layout-зависимое свойство меняется между кадрами. Если значения одинаковые, width или height больше не мешают opacity и transform работать на compositor.

Особенно заметна эта оптимизация во View Transitions. Chrome сам генерирует для них анимации с width и height, даже когда геометрия элемента остаётся прежней. До исправления такие переходы могли без необходимости фоллбека в основной поток.

В первой реализации, правда, нашлась проблема с округлением:

97.984px
97.9844px

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

Но чудес не произошло. Если размер действительно меняется:

@keyframes expand {
from {
width: 100px;
}

to {
width: 300px;
}
}

браузеру всё ещё приходится пересчитывать layout на каждом кадре. Такая анимация остаётся в основном потоке. Chrome не превращает её автоматически в transform: scale().

Для подобных случаев в CSSWG обсуждают отдельный механизм, условный size-animation, но к июлю 2026 года это всё ещё только предложение без готовой спецификации и реализации.

Так что старое правило остаётся в силе: реально меняющиеся width и height лучше без необходимости не анимировать. Chrome лишь убрал случай, когда неизменяющийся размер мешал нормальной compositor-анимации.

#performance

#заметка дня

Новости для Java-, Kotlin- и Scala-разработчиков: 29 августа в Москве пройдет JVM Day — конференция для разработчиков, архитекторов и тимлидов от Т-Банка.

Из спикеров конференции – Андрей Кулешов, который поделится последними новостями в области Java, Антон Курако объяснит, как красивые показатели могут ввести в заблуждение, а Сергей Петрелевич разберет Mechanical Sympathy и подходы к ускорению Spring Boot-приложений. На конфе также будет аллея продуктов, где можно потыкать демки фреймворка Kora для Java и Kotlin, AI-native-платформы SourceCraft и мультиязычной OpenIDE.

После докладов пройдет вечеринка во дворе штаб-квартиры Т-Банка с играми на Sega, ИТ-квизом и диджей-сетом на виниле.

Зарегистрироваться на конфу можно тут: https://meetup.tbank.ru/conference/jvm-day/.
Если вы собираетесь на конференцию, дайте знать в комментах. Так будет проще найтись и пойти вместе.

#ai #performance #java #jvm