Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Иван Акулов — Google Developer Expert в веб-технологиях и основатель перформанс-компании PerfPerfPerf. Уже совсем скоро на HolyJS 2019 Moscow он проведет воркшоп, посвященный, как ни странно, перформансу — поиску проблем в React, дебагу медленных приложений и другим рантайм-вещам.
Чтобы больше погрузить читателей и посетителей HolyJS 2019 Moscow в тему, мы обсудили с Иваном:
- Самые популярные проблемы перформанса;
- Чем измерять производительность и в чем могут быть проблемы;
- Как оптимизировать перформанс;
- Поиск проблем с производительностью в React;
- Пользу перехода на HTTP/2 и HTTP/3;
- Паким фреймворком лучше пользоваться на новых проектах;
- О пользе WebAssembly;
- Где искать полезную информацию о перформансе;
- О чем будет его воркшоп и кому на него будет интересно прийти (и зачем вообще ходить на воркшопы).
Вопросы задают Дмитрий Махнёв и Артём Кобзарь из программного комитета HolyJS.
О том, чем занимается и как пришёл в перформанс
Дмитрий: Расскажи пару слов о себе.
Иван: Я Иван Акулов, performance-консультант, Google Developer Expert, делаю своё performance консалтинг-агентство.
Дмитрий: Ты говоришь, что консалтинг-агентство — не основная работа. А в основном ты чем занимаешься?
Иван: Моё время сейчас распределено примерно так, что я наполовину загружен работой с одним давним клиентом. Я работаю с одной бразильской компанией, мы вместе делаем Wordpress контент-маркетинг платформу, я там рулю инфраструктурой и немного развитием продукта, и каким-то общим видением.
Остальное время я уделяю консалтингу, выступлениям, статьям и всему такому.
Дмитрий: Много ли обращений по перформанс-консалтингу? Как это вообще работает?
Иван: В целом это очень зависит от месяца или чего-то такого…
Дмитрий: Когда астрологи объявляют месяц перформанса? :)
Иван: Скорее, когда бухгалтеры объявляют новый квартал! (смеется). Я сейчас активно не ищу клиентов, основная причина — сейчас на это нет времени, поскольку я и так загружен тем, что есть. Но в целом все выглядит так, что я пишу какие-то статьи, делаю какие-то выступления, а при работе с какими-то клиентами меня запоминают и рекомендуют новым. В основном люди приходят благодаря нетворку, и приходят довольно прикольные чуваки.
Артём: А как ты вообще пришел к перформанс тематике до того, что аж свою консалтинговую фирму создал?
Иван: Вообще всё началось с того, что мы однажды старый-старый проект в Epam переписывали полгода на wepback. Там был старый проект с кучей легаси, со своим фронтенд-фреймворком, половина которого работала в java-стеке. И поскольку мы полгода потратили на то, чтобы webpack работал относительно быстро, у меня появился опыт работы с webpack. И в тот период я мог написать webpack-конфиг средней сложности, строк на 20—40, буквально из памяти, ничего не гугля, не подглядывания и даже не пользуясь IntelliSense.
И я понял, что такой опыт может быть полезен кому-нибудь ещё, решил попробовать начать какой-то консалтинг в области webpack. Сделал себе лендинг, запостил его куда-то, пришли пара человек, с одним из них я поработал. И как-то так всё началось.
А позже я плавно перетек из webpack related перформанса в performance-консалтинг в целом.
Артём: А на том проекте удалось улучшить перформанс сборки?
Иван: С тем проектом получилось не идеально, не так, как мне бы хотелось получить в итоге. Там было такое дело, что ребята пришли в тот момент, когда мне очень нужны были деньги и ещё не понимал, как мне вести переговоры, заботиться о себе и учитывать свои интересы в этих переговорах. Я предложил какой-то небольшой фиксированный прайс при незафиксированном объёме работы, мы поработали, я им помог, сделал какое-то решение, которое вроде бы сработало, и починил перформанс.
Потом обнаружилось, что в этом решении есть баги, оно оказалось переусложнённым и в редких edge-кейсах выскакивали странные баги. Мы начали это чинить, я починил один, второй, третий баг, всё это растянулось на месяц. И в итоге в какой-то момент баги перестали происходить, но ребята решили меня попросить о чем-то ещё, но так как у меня внутренний бюджет на это всё уже совсем закончился, я просто сказал: «Простите, я уже загружен, и не смогу помочь».
В итоге, насколько я узнал, они через пару месяцев заменили это решение на какое-то другое, менее сложное и работало в 100% кейсах.
Я, честно говоря, сам не знаю… Вроде бы я пришёл и помог, и то окончательное решение, которое они сделали, родилось у нас ранее в общих разговорах, но я при этом не знаю, сколько им помогло то, что я сделал. И насколько они были удовлетворены этим всем. Короче, это было не так идеально, как мне бы хотелось.
Артём: А если говорить про сегодняшний день, ты как-то отслеживаешь прошлых клиентов, как у них там дела, помогло ли это всё?
Иван: Да, определенно. Я постепенно выработал какие-то подходы. Во-первых, я у каждого клиента стараюсь в конце работы взять какой-то публичный фидбэк, который можно разместить на сайте или запостить куда-то.
Во-вторых у меня выработался подход спрашивать у клиентов в процессе или конце работы вопрос «How are you satisfied by the current process, current workflow, current something?» с вариантами ответа «more than satisfied», «satisfied», «almost satisfied», «not really satisfied».
И мне нравится этот вопрос, потому что он дает конкретные варианты ответов, а не какую-то глупую шкалу от 1 до 5, которую все воспринимают по-своему. Пока что никто из клиентов не отвечал «almost satisfied» или «not really satisfied». Это были «Satisfied», «Happy» и что-то такое.
Артём: А правильно ли я понимаю, что у тебя область экспертизы по перформансу в основном нацелена на клиентскую часть? Или у тебя в целом весь веб-стек затрагивается в консультациях?
Иван: Да, область экспертизы в основном нацелен на клиентский стек, с оптимизацией перформанса в бэкенде или в базах данных я работал гораздо меньше. Но на практике, если веб-приложение тормозит, даже какая-то статья или исследование есть, что 80-90% случаев — тормозит именно из-за фронтенда.
Если клиент приходит, и у него что-то тормозит, в большинстве случаев моей экспертизы в самый раз.
О самых популярных проблемах
Артём: А как вообще происходит, когда какие-то edge-кейсы? Когда у нас проблема не с парсингом JavaScript и его запуском, а проблемы с транспортом. Когда first interaction и как бы на клиент возлагается, и на бэкенд. Банально gzip неправильно настроили, он слишком долго крутится. Как в этих кейсах ты поступаешь? И если анализ у тебя в основном на фронтовую часть, как ты находишь такие кейсы?
Иван: Ну это обычно выражается в том, что время ответа от сервера становится слишком большим. Если это замечаю во время какого-то аудита, я смотрю в devtools, смотрю в network и вижу, что время от сервера 800 мс — офигеть, что-то слишком долго. И я иду, пытаюсь понять, как у ребят устроен сервер, что они делают во время каждого ответа. Если это JavaScript или PHP, я в этом, скорее всего, смогу разобраться нормально и всё пофиксить, если другой какой-то язык, с которым я не работал, может понадобиться их помощь.
Дмитрий: А ты можешь назвать какие-нибудь топ-5 самых распространённых проблем с производительностью, которые встречаются на практике?
Иван: Я буду идти по тому, как я вспоминаю. Одна из частых проблем, которая встречается не в сложных веб-приложениях, а на простых сайтах, это когда разработчик или клиент кладет много скриптов внутрь тега head без атрибутов async или defer, и это плохо, потому что браузер не может начать рендерить страницу, пока не загрузит и не выполнит эти скрипты.
И если там медленный сервер или большой скрипт, который долго выполняется, то человек, который пользуется сайтом, не увидит страницу вплоть до конца выполнения.
Ещё частая проблема — это third party скрипты. Я сейчас работаю с клиентом, которому помогаю улучшить их lighthouse score. Изначально lighthouse score у них был что-то около 35-40. Я пришел, сделал всякие разные штуки, поудалял лишние JavaScript, render-blocking resources, оптимизировал ещё как-то… После всего того, что я сделал, score вырос только где-то до 55-ти. И оказалось, что если с этой оптимизированной страницей пойти и закомментить один-единственный React-компонент, который грузит всю аналитику, lighthouse score подскакивает где-то до 88-90+ баллов. Это происходит, потому что загружается очень много JS, которые отдаляют метрики.
В каких-то сложных web-приложениях частая тема, когда разработчики устанавливают какую-то большую библиотеку и она бандлится в бандл целиком, хотя целиком не используется. Часто это Moment.js, в котором есть огромные файлы локализации,165 KB минифицированных файлов локализации, которые практически никому не нужны, или lodash, в котором куча методов, а все используют только 10-20.
С rendering performance раньше была частая проблема, когда разработчики вешали какой-то обработчик событий, например, на event scroll, он занимал 5-10 мс, и каждый раз, когда ты пытался что-то проскроллить, вся страница лагала. Сейчас этого стало меньше, потому что в том же Chrome [добавили passive event listeners](https://stackoverflow.com/questions/37721782/what-are-passive-event-listeners).
О том, чем измерять производительность
Дмитрий: По ходу кейсов всплыл вопрос про Lighthouse. По-моему все трое были на BeerJS Summit, и там был крутейший доклад — (соточка) от Алексея Калмакова. Записи нет, но я видел подобную статью на Хабре, и такие штуки немного компрометируют Lighthouse. Если брать его, чисто как инструмент, по которому оценивать работу performance-инженера, там можно сделать некоторые трюки.
Есть ли у тебя какие-то инструменты, может даже самописные, по которым ты четко оцениваешь, получилось или нет. Например, ты заключаешь контракт и тебе говорят, что надо сделать performance x2. Каким набором инструментов ты для этого будешь пользоваться?
Иван: Ну, во-первых, если мы будем заключать контракт и будем договариваться про x2, то договоримся на какой-то инструмент. А в целом, помимо Lighthouse мне очень нравится WebPageTest. Это очень клёвый advanced web performance tool, который позволяет протестировать твоё приложение из реальной произвольной локации, например, Бразилии или Австралии, на реальном, например, очень слабом устройстве, типа Moto G.
Это круче, чем Lighthouse, потому что он все это эмулирует, а только после тестов на реальном устройстве ты узнаешь, что сайт рендерится 15 секунд. Вторая польза — он даёт кучу супер подробных метрик всяких чартов, типа загрузки. Я его регулярно использую, чтобы посмотреть на какие-то штуки.
Дмитрий: А писал ли ты какие-нибудь свои инструменты, например, поверх Chrome DevTools Protocol? Чего тебе не хватает в инструментах?
Иван: Я писал свой инструмент поверх Lighthouse. Мне для работы с одним из клиентов нужен был сетап, который позволил бы в достаточно стабильном окружении измерять перформанс одной страницы Lighthouse-ом, считать его lighthouse score и скопировать в таблицу. С ним вообще проблема: Lighthouse в PageSpeed Insights не очень стабилен. Если измерить три раза одну и ту же страницу, можно получить три разных измерения. К тому же, мне нужно было измерять не готовые и опубликованные в сети страницы, а локальную. И единственный вариант — запускать Lighthouse локально, что тоже очень влияет на lighthouse score, т.к. score начинает зависеть от того что работает у тебя на ноутбуке. Например запустил Docker, score упал в 2 раза.
Для этого кейса мне нужно было измерять Lighthouse предсказуемо. Я написал скрипт, который запускал Lighthouse три раза, браз score, брал медианное значение из этих трёх раз, и делал это для множества страничек со множеством сетапов. Я арендовал для этого DigitalOcean-сервер и запускал там всё, чтобы сделать максимально изолированным от внешних факторов.
Артём: Ты упомянул интересный кейс про разные метрики Lighthouse. Тут недавно была статья An introduction to 99 percentile for programmers, в которой как раз делали выводы, что современные инструменты-бенчмарки и в принципе микробенчмаркинг сам по себе ничего не доказывает.
Что современными инструментами вполне может получиться так, что я сделал бенчмарк, ты написал, Дима написал, и все они будут говорить абсолютно разные вещи. И что сейчас в мире без каких-то более-менее глубоких знаний в теорвере и статистике не слишком правдоподобным кажется бенчмаркинг. Ты упомянул про Lighthouse, а есть ли какие-то подтверждения тому, что ты получил в бенчмарке, какое-то дополнительное подтверждение?
Дмитрий: Может быть, миксовать Lighthouse с чем-то? Ты упомянул WebPageTest. Мы берем их, может ещё наблюдения из Chrome DevTools, и как-то их миксуем?
Иван: Вообще, в идеале, если на каком-то проекте есть что угодно, что позволяет трекать RUM (real user metrics) — как реально сайт грузится у каких-то пользователей, и если мы можем выкатить это на реальных пользователей и посмотреть, как у них это сработало — это идеальный кейс.
А в целом да, если я юзаю какой-то инструмент, я действительно запускаю больше одного теста, чтобы получить медианное значение, но в целом статья приводит реальную проблему про то, что есть какой-то 99-й перцентиль пользователей, у которых всё очень плохо и не узнаем, если просто юзаем Lighthouse, но это не говорит, что Lighthouse бесполезен, он по прежнему продолжает работать и показывать среднюю температуру по больнице. Если в целом мы улучшили производительность, Lighthouse это покажет.
Дмитрий: Ты затронул real user metrics. Я просто работал в «Одноклассниках» и у нас были проблемы с тем, как это трекать, потому что это непонятно как делать, и объёмы большие. Мы и своё что-то писали, и с пользователей собирали, и это просто какой-то хаос был. А если всё-таки какой-то средний проект, что можно взять, чтобы мерять на стороне пользователя? Просто window.performance или что-то ещё порекомендовал? Или какие-то хитрые тактики использовать, обстрелы на реальных аккаунтах пользователей?
Иван: Во-первых, наверняка есть готовые библиотеки или сервисы, которые позволяют настроить RUM. Например, одной строкой добавить на страницу и это начнет трекаться. Во-вторых, в современных браузерах появилась такая штука как PerformanceObserver — это API, которое измеряет всякие штуки в браузерах и позволяет узнать метрики, которые браузер обычно держит внутри, включая first contentful paint, first meaningful paint и всего такого. И чтобы узнать эту метрику, достаточно всего нескольких строк кода, не нужно писать что-то переусложненное. Подписался на события, получил его и затрекал.
Дмитрий: А на что больше всего надо обращать внимание в первую очередь? First Paint, time to interactive, time to first byte, что-то ещё?
Иван: У меня про это как раз [есть доклад](https://www.youtube.com/watch?v=-H1l9XBXH6Q) и я в нем рассказываю, что самые важные штуки, на которые нужно смотреть — это first meaningful paint и time to interactive. И они максимально важны, так как показывают именно то, за чем в первую очередь пришёл пользователь. Он пришел либо что-то почитать или посмотреть, тогда это first meaningful paint, либо поработать с приложением, тогда это time to interactive. Если вы делаете какой-то лендинг или новостной сайт, то оптимизируйте first meaningful paint, а если сложное приложение то оптимизируйте first meaningful paint и time to interactive.
Артём: Мы упомянули самые популярные кейсы в твоей практике. А какие кейсы самые редкие или интересные, в которых приходилось куда-то докапываться прямо в кишочки?
Иван: Я думаю, что у меня сейчас довольно интересный кейс. Я сейчас работаю с Framer. У этих ребят модный дизайн-тул, аналог Figma и Sketch. И я им помогаю улучшить runtime performance — это вообще супер интересная для меня зона. Они используют браузер супер по специфическому. Браузеры изначально не предназначены для написания таких сложных приложений, поэтому и Figma, и Framer реимплементят много браузерных штук сами. И там куча своих разработок, которых нет на других проектах, и которые супер интересные. Я получаю огромное удовольствие от работы со всем этим. Это реально что-то интересное, что-то новое и очень круто.
Как оптимизировать перформанс
Дмитрий: Мы поговорили про основные браузерные нюансы, и прежде чем перейти к фреймворкам, хотелось бы узнать про оптимизацию перформанса с помощью архитектуры, каких-то структур данных. Приходилось что-то такое основательное менять в приложении, например, добавлять префиксный список для поиска или ещё что-то не очень обычное для фронтенда? Бывает ли такое?
Иван: На уровне структур данных или algorithmical complexity я практически не работал, потому что нужно сделать очень много всего, чтобы приложение тормозило именно в этом, а не чем-то другом. А так, по поводу крупных штук, я очень всем рекомендую при создании нового проекта или если проект только начался и он ещё совсем небольшой, делайте его на фреймворке типа Next.js или Gatsby.
И то, и другое — это фреймворк для React, который построен так, чтобы вы просто писали приложение с использованием пары подходов этого фреймворка, а оно автоматически становилось быстрым. И это очень популярные фреймворки, они отлично делают свою задачу, я сам их юзаю на своих продакшн-проектах и очень всем рекомендую.
Артем: Как раз тут у нас недавно был казус, связанный с тем, как V8 деоптимизировал React из-за устройства Number внутри V8. Почувствовал ли ты это issue или были ли какие-то поиски, почему приложение тормозит?
Иван: Не почувствовал, и не читал эту статью по поводу деоптимизации. Там была какая-то конкретная операция или тормозил весь React в целом?
Артём: В целом, потому что в React, внутри FiberNode есть timestamp, и он изначально выставляется в 0 и запрещали расширение (preventExtension), и для этого выделялся один shape с small integer, чтобы оптимизировать операции над числами. А когда timestamp заполняли реальным значение, которое вылазило за 128, получалось так, что нужно было менять структуру с small integer на mutable heap number, а поскольку был вызван preventExtension, строилcя абсолютно новые shape для каждого fiber node. А их десятки и сотни тысяч.
Иван: Я такого не замечал, и вряд ли бы заметил, потому что, когда дебажу, у меня нет такого в памяти, что эта операция должна в React занимать только 10 мс, а она занимает 20. Я просто дебажу, смотрю performance trace, выбираю какие-то bottleneck, где что-то тормозит. Если performance распределен, есть какие-то лаги в V8 и распределены равномерно по всему приложению, то если не уйду в совсем глубокие дебаги, то не замечу.
Если это будет происходить в одной деоптимизированной операции V8 и она занимает долгое время, я замечу и уйду в глубокий дебаггинг.
Артём: А был ли вообще какой-то issue самого React, или других фреймворков, где приходилось создавать issue, докапываться до чего-то?
Иван: По-моему, я репортил пару багов, но деталей не помню… Не думаю будет ли это релевантно к данному вопросу, но я недавно наткнулся на интересный кейс, когда css-переменные оказывались медленнее, чем изменения приложений путем React prop-ов. И для меня это ощущается странно, потому что мы привыкли говорить, что css супербыстрый, а тут внезапно он работает сильно медленее, чем React.
Я пытаюсь дописать про это статью, и в целом это работает так, потому что в браузерах нет оптимизации — если ты поменяешь css-переменную на элементе, у которого очень много детей, то браузер, по крайней мере, Chrome, не запоминает, какие именно дети используют эту переменную и он идёт и вычисляет всех детей и стили для них. Если там много стилей и узлов — это много времени, а если заменить какую-то переменную поменять React’ом, то может быть вычисления стилей может не происходить и это все произойдёт быстро.
Я на 80% уверен, что это так по тому, что я понял по коду V8, но могу ошибаться. Но эта та штука, которую можно было бы зарепортить и починить в браузерах, но это не микробаг, возможно, там много работы. Я это не репортил пока и не знаю, как много времени уйдет на исправление, если я это зарепорчу.
Артём: А приходилось ли смотреть результирующий байткод? С теми же просмотрами деоптимизации, смотришь байткод V8, а там какие-то лишние операции вставляются?
Иван: Нет, в байткод я наверное ни разу не смотрел, но я довольно хорошо научился читать минифицированный JavaScript. (смеется)
Дмитрий: А ещё к предыдущему ответу — а ты как-то общаешься с разработчиками браузеров, чтобы уточнять такие штуки? И если да, то как они отвечают? И отвечают ли?
Иван: Мне помогает статус GDE (Google Developer Expert), благодаря этому меня добавили в Google-репозиторий и Slack-канал, где могу пинговать напрямую Google-команды, включая разработчиков Chrome. Я один раз пользовался этим для какого-то сложного клиентского кейса, хотел подтвердить у них одно поведение. Мне ответили в течение пары дней, нормально. Всё ок. Но больше этим пока не пользовался.
Дмитрий: Круто! Теперь понятно зачем этот статус нужен.
Иван: Ещё я сейчас нахожусь в Лондоне благодаря билетам, которые мне купил Google, поэтому GDE нужен ещё для этого (смеется).
Дмитрий: Второй плюсик :)
Иван: Для этого, правда, нужна прилететь и выступать на конференции, которая этого не оплачивает.
О выборе фреймворка
Дмитрий: Мы уже немного говорили про бандлинг, и ты упоминал очень классный кейс с Moment.js. Я помню, Андрей Ситник рассказывал, что его можно заменить на Day.js или ещё что-то, если посмотреть на bundlephobia. Но бывает, что ты используешь, например, Angular, и там сразу много всего приезжает.
Я его использую, потому что, мне кажется, по их подходу и тому, как они пишут, что это построено на типах, по статическому анализу, у них есть некий запас прочности, когда они это потом оптимизируют. Что ты думаешь по таким кейсам? Можно ли посмотреть со стороны на фреймворк и выбрать его, несмотря на некоторые issue по перформансу, но в будущем обещают их починить? Если да, то какие критерии доверия для этого ты бы выбрал?
Иван: Сложный вопрос… Не знаю. Всё-таки если бы я выбирал фреймворк, я бы выбирал его в первую очередь, исходя из популярности. Потому что мне как тимлиду какого-нибудь проекта было бы важно, чтобы для этого фреймворка было много разработчиков и много сторонних библиотек, userspace-комьюнити и компонентов.
Я не думаю, что я бы ориентировался на перформанс как на первый критерий выбора фреймворка.
С другой стороны, если фреймворк достаточно популярен, я думаю, перформанс-оптимизации для него в любом случае сделают. Начиная с банальных webpack хаков с код сплитингом и чем-то таким и заканчивая более лёгкими альтернативами. У React, например, есть куча лёгких версий с похожим API типа Preact, Inferno.
Дмитрий: А что бы могло тебя остановить в выборе фреймворка? Вот он такой популярный, у него большое комьюнити, как, например, в Vue.js, огромное количество людей, видно, как они взаимодействуют. Что может для тебя явиться стоп-сигналом?
Иван: Я бы точно не выбирал фреймворки, которые идут на спад. Честно, я не знаю, как дела у Angular, я не работал с Angular. Но если посмотреть статистику скачиваний Angular, я не уверен, что она не будет идти на спад. Надо проверить прямо сейчас… Нет, она растёт, клёво. Какой-нибудь Ext JS точно будет идти на спад.
А так я даже не знаю, что ответить. У меня нет абстрактного ответа, я бы просто смотрел каждый раз из имеющихся реальных альтернатив и имеющихся реальных окончаний проектов. Всё зависит от конкретного кейса, у меня нет общего ответа.
О WebAssembly
Артём: Бывало ли такое, что упираешься в какие-то проблемы JS, допустим, если мы говорим про high computation проблемы. Приходилось ли советовать или самому прототипировать WebAssembly, чтобы убрать computational проблемы?
Иван: Очень хотелось бы поработать с таким кейсом, WebAssembly и оптимизацией чего-то низкоуровневого и алгоритмического, но таких кейсов пока не было.
Артём: Я так понимаю, в текущей компании, которую ты консультируешь может быть WASM. Если мы просто проведем параллели с Figma, она вроде сама на Blaser, на C# WebAssembly, и как раз из-за этого у них работа с графикой и расчетами ужимается по времени. Может в твоей текущей компании такие кейсы есть или ты до них не дошёл?
Иван: Я не уверен, что имею право что-то комментировать по поводу WebAssembly в этой конкретной компании. В целом, c WebAssembly я хочу поработать, но пока не работал. Практических кейсов у меня не было.
Дмитрий: А как ты вообще на него смотришь и чего ты от него ожидаешь?
Иван: Это инструмент, который помогает решать конкретные задачи. Если у вас есть что-то, что занимает много времени в JavaScript из-за большой алгоритмической сложности, это можно переписать на WebAssembly и ускорить в, скажем, три раза или в 10 раз.
Или если есть сторонняя библиотека, которую хотите заюзать, но которой нет в JavaScript, но есть в C++ или Rust — это тоже можно скомпилировать в WebAssembly и заюзать. Это не решение всех проблем, это очень узкий и четкий инструмент, который решает конкретные задачи.
О платформах
Дмитрий: Давай перейдем к платформам. Мы немного затронули scroll, и как я помню, это проблема на мобилках. Сталкивался ли ты с чем-то люто-бешеным на мобилках? Например, в Chrome на iOS или были какие-то кейсы в ChromeOS или где-то ещё, на каких-то полуэкзотических платформах? Или, не знаю, «Яндекс.Браузер»?
Иван: Ко мне однажды приходил один клиент, которому была нужна performance оптимизация под IE11. Им это было важно, потому что там была гемблинг-платформа или сайт, и оказалось, что там большой процент клиентов пользуется IE11. Но у нас не срослось, мы не поработали. Поэтому я так и не пооптимизировал под IE11.
Кроме этого особо ничего не было. «Яндекс.Браузер» и Chrome на iOS на самом деле не экзотики, потому что «Яндекс.Браузер» тот же Chromium, а Chrome на iOS — тот же WebKit, там у всех браузеров один движок на iOS
Дмитрий: Ну, там есть маленькие различия… Бывает (вздыхает)
О транспортных проблемах и переходе на HTTP/3
Артём: А если мы перейдем с того, что зависит от клиента к тому, что не особо зависит. Это про транспорт. У нас вроде как все постепенно переводятся на HTTP/2, при этом уже реализован HTTP/3, тот самый протокол QUIC. Вопрос двоякий, наверное: действительно ли сильно помогает мультипуш с HTTP/2 по метрикам, которые мы упоминали ранее?
И были ли кейсы, когда ребята переходили на HTTP/3 и все метрики бустило на порядок?
Иван: А HTTP/3 уже реализован и запаблишен?
Артём: Да, он в Chrome точно реализован, добавили в cURL, насколько я помню.
Иван: О, круто. Потому что, когда я в последний раз это всё проверял, помню, что протокол, который лёг в основу HTTP/3 точно был реализован и поддерживается. То есть Google сначала сделал протокол, а потом он лёг в основу HTTP/3, и я не был уверен, был ли закончен HTTP/3.
Судя по тому, что я видел, HTTP/2 определенно помогает и точно полезен во фронтенде, потому что, если вы грузите больше, чем 2-3 файла со своего сервера, что происходит практически во всех случаях, то с HTTP/2 это грузится быстрее в среднем. HTTP/3 я ещё на практике не тестил. Но мне интересно, я жду какого-то кейса, когда смогу пощупать его руками.
Где искать полезную информацию по перформансу
Артём: А вообще, откуда ты потребляешь информацию, в каком виде? Статьи, блоги конкретных браузеров, твиттер-аккаунты конкретных разработчиков браузеров?
Иван: Во-первых, я беру пачку инфы из Twitter, там порой всплывают статьи (например, [раз](https://twitter.com/slightlylate), [два](https://twitter.com/zachleat), [три](https://twitter.com/csswizardry), [четыре](https://twitter.com/igrigorik), [пять](https://twitter.com/philwalton)). Во-вторых Google проводит для GDE ежемесячный созвон, где рассказывает про какие-то новые изменения в веб-платформе или performance-оптимизации. Это довольно интересный источник информации.
В третьих, ребята из Calibre (это инструмент для performance-мониторинга) есть классная ежемесячная рассылка Perf.email, в которой собирают всякие ссылки на новые performance-статьи.
Дмитрий: Мы нашли третий плюс GDE! Если идти в тему нахождения информации, ты ведешь отличный телеграм-канал, в котором всем этим делишься. Например, хватит ли мне читать только этот канал и ещё пару маленьких источников, и вообще, как возникла идея создать и развивать? Насколько я понимаю, это не очень просто.
Иван: Не знаю, Service License Agreement у меня нет, поэтому я не буду покрывать 95% статей. Я стараюсь туда кидать, что я сам читаю по performance и что мне интересно. Мне ещё очень нравится канал Juliarderity, который ведут Серёжа Рубанов и Роман Дварнов, я его прямо очень люблю, они очень классные. Пишут туда свежие апдейты браузеров, стандартов и всего такого.
Дмитрий: Я его называю просто «самый лучший канал в телеграме», это проще, чем название. А насколько ты считаешь важным следить за именно апдейтами языка? Если я являюсь React, Angular и т.д. разработчиком — такой framework-specific разработчик, насколько мне важно понимать, что с языком происходит? Насколько важно следить за движухой TC39?
Иван: Я не знаю (смеется). Если считаете, что для вашей карьеры это будет полезно — следите, но если никак не влияет — не следите.
Дмитрий: А твоей карьере это полезно?
Иван: Я не замечал какой-то особой прямой пользы от слежки. Я не слежу за последними proposal, кроме тех, что ребята постят в канал. И я не замечал пока для себя никакой пользы от слежки за этими proposal, мне полезнее какая-то инфа про свежие релизы браузеров и следить за изменениями в них. А изменения в языке — нет.
Дмитрий: А по браузерам, хватает просто подписаться на их RSS? По-моему они у всех есть.
Иван: Я не подписан на их RSS.
Дмитрий: Это просто очень прикольно, когда заходишь на Habr, там «Новые апдейты в Chrome», а ты их неделю назад в RSS прочитал прямо от них. RSS древний, но мощный.
Иван: Не знаю, я по-моему, подписан на них в твиттере, по крайней мере, на DevTool-аккаунты, наверное, что-то узнаю оттуда, но формального источника, который регулярно проверяю, нет.
Артём: По поводу создания канала, как пришла идея?
Иван: У меня уже был Twitter, захотел поэкспериментировать с разными новыми форматами и платформами, создал телеграм-канал, запостил его в Twitter, на него подписалось 20-30 людей. И я посмотрел на это, и твитнул твит с содержанием «@vkozula Сколько у тебя стоит прорекламировать канал?».
Он не ответил, но через сутки сам запостил в свой канал «Вот Ваня Акулов, подписывайтесь на его канал». И мне это сразу бампнуло число подписчиков что-то около тысячи. Потом Женя Родионов буквально через день запостил у себя. Потом это росло уже органически, с рекомендациями от других чуваков. В целом, получился удачный эксперимент. Я тогда завёл и Facebook-комьюнити, но в нём где-то 50 человек лайкнуло, и я его забываю обновлять, на самом деле.
Дмитрий: А jsunderhood как-то помог?
Иван: У меня не было цели напрямую набрать себе подписчиков в underhood. По-моему он привел довольно неплохое количество, да. Я в первый раз вел underhood, было интересно это попробовать и моя небольшая гордость — сайт jsunderhood не обновляется с 2017 года, к сожалению, но по моим подсчетам я по сравнению со всеми ребятами, что есть на сайте, я привел больше всего подписчиков, даже больше, чем Вадим Макеев.
О пользе воркшопов
Дмитрий: Мы, на самом деле, решили позвать тебя на HolyJS с воркшопом именно после jsunderhood, т.к. ты просто смыл нас потоком информации. Что ты вообще думаешь по поводу этого формата? Можно ли его рассматривать, как классную новостную штуку или хороший источник знаний?
Иван: Формат очень прикольный, и очень кайфово, что туда приходят разные люди со своим взглядом или своим специфическим опытом и начинают материться. Проблема с ним для ведущих, в частности, в том, что… Я написал туда кучу инфы, но я на это потратил половину своего времени, которое должен был потратить на работу. У меня это конкретно заняло 10—20 рабочих часов.
Дмитрий: То есть, такую движуху сначала нужно согласовывать с работодателем?
Иван: Да, мне повезло, потому что я консультант и у меня нет никакой отчетности, поэтому я это всё вместил, но, думаю, довольно много людей с этим сталкивается, что хотят рассказать многое, но у них на это не хватает времени. А для меня ещё, как для читателя, проблема в том, что это Twitter и там больше подписок, чем я осиливаю, и я много чего пропускаю. Кто-то недавно сделал трансляцию из Twitter в Telegram и это очень кайфово, можно зайти раз в несколько дней и прочитать все посты, ничего не пропустив.
Артём: Если мы перейдём к ещё одной деятельности, которую ты не упоминал. Ты же ведешь воркшопы, у тебя вроде как большой опыт в этом. Какие свои воркшопы в публичном доступе ты считаешь добротными, на которые стоит взглянуть и ты считаешь сам, что они удались с точки зрения подачи контента в целом и посетители остались довольны?
Иван: Я проводил не так много воркшопов в абсолютном количестве, но чем я больше всего горжусь — это мой воркшоп по webpack, который я делал как введение в webpack в конце 2017 года. К сожалению, он уже устарел, но получился клёвым, потому что я планировал провести онлайн-трансляцию, но в тот день у меня начал дико лагать интернет.
Я начинал вести, через 10 минут отваливался, переподключался, снова отваливался и мне пришлось это всё срочно отменить, извиняться и говорить, что запишу весь материал на видео и выложу это всё так. Я это всё сделал, выложил, получилась серия видео как на egghead.io, и за исключением проблемы, что там очень тихий звук, потому что не было нормального микрофона. Я слышал много отзывов, что было очень хорошо и людям очень помогло.
Дмитрий: Как ты считаешь, для чего вообще стоит идти на воркшопы? Например если ты пошёл на воркшоп по браузеру, я часто слышу, что люди хотят увидеть как V8 распотрошите или ещё что-нибудь. А на западе наоборот, если вспомнить классное интервью Michel Weststrate, он говорил «Я иду на них учиться. Если я совсем не знаю Docker, то иду туда и быстро получаю информацию». Как ты видишь воркшопы и в каких случаях ты рекомендуешь посещать свои воркшопы? Научиться, углубить знания, увидеть кишочки?
Иван: Я бы сказал так — если описание вам показалось интересным, то приходите. Когда я делаю воркшопы, всегда стараюсь дать какую-то базу, чтобы те люди, кто пришёл и работает с этим в первый раз, не потерялись. Я могу представить, что каким-то ребятам, которые работают в super advanced пришли послушать, может быть начало скучным. Они могут не остаться до конца, где могут подниматься advanced тема. С другой стороны, я не могу обещать, что я буду показывать какие-то кишочки, потому что у всех людей понимание «кишочков» разное. Я приду и буду показывать какие-то супер редкие кейсы, с которыми сталкивался в своём опыте, а кто-то другой может прийти и надеяться, что я буду дебажить V8 или компилировать Chromium, а я этого делать не буду.
Дмитрий: А что ты сам, в принципе, обычно ждёшь от воркшопа?
Иван: Я помню, ходил только на пару воркшопов в своей жизни. Оба раза это была какая-то новая тема для меня, до которой я все никак не мог добраться разобраться сам. И воркшопы были каким-то introduction для меня, и это было суперполезно.
Я в своём воркшопе не буду делать совсем introduction в performance и в React, рассчитываю, что люди, которые придут, что-то об этом слышали, но стараюсь покрыть и какие-то базовые темы, и показать какой-то advanced дебаггинг настолько, насколько я его знаю и с ним сталкивался.
Дмитрий: Что ты вообще ожидаешь от HolyJS в целом? Может приметил какие-то доклады или докладчиков, с которыми хотел бы пообщаться?
Иван: Я ничего себе не планирую больше, чем на месяц вперед, поэтому пока ничего не планировал. Идет подготовка, а остальное как случится. (смеется)
Дмитрий: На этом всё. Большое спасибо за интервью. Ждём всех на твоём воркшопе.
