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

Вы, конечно, все в курсе, что порядок подключения ресурсов сильно влияет на скорость отображения страницы, на 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://t.me/htmlshit/3317

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

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

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

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

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

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

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

#advent #calendar #webperf #performance