​​4️⃣ Отложите до клика на нужную кнопку

Если у вас на сайте есть какой-то чат-виджет (типа Intercom), это виджет часто не нужен, пока пользователь не кликнет на кнопку чата. При этом виджет всё равно загружается в фоне и забирает на себя CPU-ресурсы.

Если у вас такой случай, загружайте виджет, только когда пользователь нажмёт на кнопку чата:

​​5️⃣ Замените сервер-сайд-тулом

У Cloudflare, Netlify и кучи других CDN-ов есть сервер-сайд-аналитика. В ней меньше данных, чем в Google Analytics — но если вам нужно просто считать просмотры страниц, её более чем достаточно.

Бонус: сервер-сайд-аналитика не блокируется adblock-ом.

​​6️⃣ Удалите с ненужных страниц

Если вы:
— показываете рекламу только на десктопе, а на мобильном прячете, или
— ретаргетите пользователей, которые зашли в корзину, а остальных не ретаргетите

то грузите скрипты рекламы/ретаргетинга только там, где они нужны.

Например, вот как можно настроить GTM, чтобы он загружал скрипт только в корзине:

​​🙅 Не надо: откладывать third party до первого взамодействия

Некоторые сайты откладывают аналитику/рекламу до первого тапа или скролла страницы. Мне кажется, это плохая идея. (Дисклеймер: на реальном проекте я это не проверял.)

Если вы будете грузить рекламу только по первому тапу, то, конечно, это улучшит ваш Lighthouse-счёт. Lighthouse не тапает на страницу, поэтому рекламу он просто не загрузит.

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

2) это, скорее всего, не улучшит и SEO. Насколько я знаю, SEO-ранжирование опирается не на Lighthouse, а на Chrome UX Report. А данные Chrome UX Report собираются с реальных пользователей — c тех, у кого реклама загружается.

🙅 Не надо: использовать requestIdleCallback

requestIdleCallback() просит браузер выполнить какой-то код, когда браузер простаивает. Это может показаться идеальным инстументом, чтобы отложить загрузку аналитики. Но это не так.

requestIdleCallback срабатывает всего через 50-100 мс неактивности. 50-100 мс вполне могут выдаться свободными, пока приложение всё ещё инициализируется. В итоге third parties загрузятся слишком рано и заберут главный поток у приложения.

Ищу ассистента 🏔

Привет! Нестандартный пост: я ищу себе классного парт-тайм-ассистента.

— 50% рабочих задач: менеджить документы, пинговать клиентов, контролировать платежи

— 50% личных: курьеры, поездки, покупки, заказы

— Буду рад поменторить — рассказать всё, что знаю про карьеру в айти, фриланс, ИП/налоги и то, как делать собственный бизнес. (Ну а вы как раз увидите это всё вживую)

— Парт-тайм (до 20 часов в неделю), ремоут, $650/месяц

👉 https://www.notion.so/iamakulov/960da52be3b145af91fd2d53bc31daa1

Перформанс-нюанс. Оказывается, браузеры не выполнят ни одного скрипта, пока не загрузят все стили страницы ↑

(Загрузка скриптов при этом не откладывается — только исполнение.)

(Источник — «CSS and Network Performance»)

Теория и практика Core Web Vitals

26 ноября (чт) выступлю на HolyJS! Вместе с Элизабет Свини (Google) расскажу про Core Web Vitals:

— Теория: Элизабет покажет, как CWV связаны с Lighthouse-скором, как этот скор считается и какие у Google планы по развитию CWV
— Практика: Я на примере реального сайта покажу, какие штуки влияют на CWV и как их оптимизировать

Приходите :) https://holyjs-moscow.ru/2020/msk/talks/ymy2hqzhonwsav8slq7yx/

(А по ужасно длинному промокоду PerfPerfPerf2020JRG ещё и скидка ~10%)

​​Writing Less Damned Code

Клёвый лёгкий доклад на выходные — про то, как делать хорошие приложения, пиша меньше кода: https://vimeo.com/190834530

Доклад рассказывает:
— что ARIA-атрибуты вам не нужны (если нужны, то вы, скорее всего, делаете что-то неправильно)
— как правильно (и как неправильно) верстать отзывчивые сайты
— что галереи и социокнопки — зло
— и как сделать SPA-приложение с нулём строчек JavaScript

В докладе шутки и немного матов (в общем, всё, как надо)

→ https://vimeo.com/190834530

Любимый фрагмент в докладе — про галереи на сайтах:

This brings me to unprogressive non-enhancement.

You take some structured content, which follows the vertical flow of the document in a way that everyone understands. Which people traverse easily by either dragging their scroll bar with their mouse, or operating the keyboard using the up and down keys, or using the spacebar.

What you do is you take that, and you fucking well leave it alone.

​​Реэкспорты и перформанс

Так, давайте поговорим про файлы-реэкспорты — и почему они плохи для перформанса.

Файл-реэкспорт — это файл, который реэкспортирует что-то из других файлов. Частый пример — это когда у вас есть папка components/ с компонентами — и в ней лежит файл components/index.js, который экспортирует все компоненты из папки ↓

​​Файлы-реэкспорты плохи для перформанса — по двум причинам.

✂️ Из-за реэкспортов код-сплиттинг работает хуже

Когда вы импортируете компонент из файла с реэкспортами:

import { Button } from '../components/index.js'

вы импортируете не просто этот компонент, а весь файл components/index.js. Это значит, что вы импортируете всё, что импортирует этот файл (= все другие компоненты). И бандлите это всё в текущий чанк.

Пример. Допустим, у вас есть огромный компонент Icon. Этот компонент используется только в коде, который вы кодсплиттите import()-ом.

Кажется, что Icon должен тоже закодсплиттиться, да? Но этого не произойдёт. Главный чанк импортирует Button из components/index.js — и вместе с этим файлом импортирует и Icon. Из-за этого Icon остаётся в главном чанке.

Кейс. Один клиент, с которым я работал, удалил файл components/index.js и заменил всё прямыми импортами. Бандл уменьшился на 200 кб:

📈 Реэкспорты делают инициализацию бандла дороже

После того, как браузер загружает бандл, он должен выполнить его — и все модули в нём. Если у вас много модулей, это может занять много времени.

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

Это ухудшает Total Blocking Time и Time to Interactive.

Кейс. Тот же самый клиент удалил файл components/index.js. Это уменьшило время инициализации бандла с 400 до 340 мс.

«А почему три-шейкинг не помогает?»
Три-шейкинг по-прежнему работает отлично — он удаляет все компоненты, которые не используются в приложении.

Но три-шейкинг не применяется к компонентам, которые используются в приложении — но не используются в текущем чанке.

​​«Окей, какие решения?»
— Либо не используйте файлы-реэкспорты вообще (иногда это ещё помогает избавиться от циклических зависимостей)
— Либо, если у вас webpack, попробуйте хак с sideEffects: false в папке с реэкспортами: https://twitter.com/wsokra/status/1331909789207638017

Как измерить third parties

Регулярная перформанс-проблема в сайтах, с которыми я работаю — это third parties (аналитика и реклама). Как оптимизировать их, я уже писал. А вот как посчитать, насколько они реально влияют на сайт — чтобы потом продавать изменения бизнесу:

​​📺 Core Web Vitals

Third-party-тулы часто ухудшают Core Web Vitals — замедляют рендер и инициализацию приложения. Вот как измерить, насколько сильно:

1. Запустите тест сайта в www.webpagetest.org. Подождите, пока тест закончится.
2. Кликните «Request map» справа сверху → «Miss the old requestmap?» внизу → «Download CSV Data».
3. Скачается CSV-файл со всеми доменами, на которые ваш сайт посылает запросы. Откройте файл и удалите оттуда домены вашего сайта.
4. Скопируйте оставшиеся third-party домены, вставьте их в какой-нибудь текстовый редактор и замените переносы строк пробелами.
5. Вернитесь в www.webpagetest.org, создайте новый тест, и в Advanced Settings → Block → Block Domains укажите все домены из прошлого пункта. Запустите тест.

(Видео с демонстрацией)

Готово, ваш сайт восхитителен:

​​🔩 JavaScript-стоимость

Основная проблема с third parties — это то, что они выполняют слишком много JavaScript-а — и блокируют главный поток страницы. Вот как понять, насколько каждый third-party-скрипт участвует в этом:

1. Откройте Chrome DevTools → Performance, включите запись и обновите страницу
2. Остановите запись, когда страница загрузится
3. Не нажимая больше никуда, в нижней панели откройте вкладку Bottom-up
4. В фильтрах выберите «Group by Domain»

Готово! Теперь вы видите, сколько времени выполнялись скрипты с каждого домена:

Бинго! Составляйте эксельку и идите разговаривать с маркетингом (только посмотрите доклад Гарри Робертса про то, как это правильно делать).

​​🦅 webpackMode: eager

Недавно узнал про import(/* webpackMode: 'eager' */).

В отличие от обычного import(), который используется для код-сплиттинга, import(/* webpackMode: 'eager' */) оставляет модуль в бандле.

(Дока)