useStore вернёт стор — и всё. Он не будет извлекать какие-то конкретные поля из стора. Он не будет перерисовывать компонент, когда что-то меняется.Когда пользователь нажмёт на кнопку, нам останется только достать актуальный
userId прямо из store.getState(). Никаких лишних ререндеров.🔗 Документация: https://react-redux.js.org/api/hooks#usestore
react-redux.js.org
Hooks | React Redux
API > Hooks: the `useSelector` and `useDispatch` hooks`
Классно и подробно про текущий статус React 18, Suspense и Server Components:
— что уже сделано
— что в процессе
— и что ещё непонятно и исследуется
https://github.com/reactwg/react-18/discussions/98#discussioncomment-1318753
— что уже сделано
— что в процессе
— и что ещё непонятно и исследуется
https://github.com/reactwg/react-18/discussions/98#discussioncomment-1318753
Как Chrome загружает и выполняет
— <script> в <head>
— <script async>
— <script defer>
— <script> в <body>
и другие вариации скриптов:
https://addyosmani.com/blog/script-priorities/
— <script> в <head>
— <script async>
— <script defer>
— <script> в <body>
и другие вариации скриптов:
https://addyosmani.com/blog/script-priorities/
Fontsource
Наткнулся на Fontsource и мгновенно влюбился: https://fontsource.org
Fontsource позволяет устанавливать через npm шрифты, которые есть в Google Fonts. Это ощутимо быстрее и улучшает LCP:
— Google Fonts требует подключить CSS со стороннего сервера (fonts.googleapis.com)
— Чтобы загрузить стили с fonts.googleapis.com, браузеру нужно сначала установить соединение с этим сервером. Это долго — 400-500 мс на 4G
— А пока браузер не скачает стили, страница будет оставаться невидимой
А вот если подключить шрифт из npm-пакета Fontsource, то стили и шрифт будут на том же сервере и загрузятся быстрее
Наткнулся на Fontsource и мгновенно влюбился: https://fontsource.org
Fontsource позволяет устанавливать через npm шрифты, которые есть в Google Fonts. Это ощутимо быстрее и улучшает LCP:
— Google Fonts требует подключить CSS со стороннего сервера (fonts.googleapis.com)
— Чтобы загрузить стили с fonts.googleapis.com, браузеру нужно сначала установить соединение с этим сервером. Это долго — 400-500 мс на 4G
— А пока браузер не скачает стили, страница будет оставаться невидимой
А вот если подключить шрифт из npm-пакета Fontsource, то стили и шрифт будут на том же сервере и загрузятся быстрее
Кайф Fontsource ещё в том, что он, как и Google Fonts, сабсеттит шрифты по наборам символов (латиница, кириллица и т.д.). Благодаря этому, если сайт целиком англоязычный, то весь файл шрифта скачиваться не будет — только символы латиницы.
Раньше, когда я перемещал шрифты из Google Fonts на свой сервер, делать такую нарезку приходилось вручную (и это было больно)
Раньше, когда я перемещал шрифты из Google Fonts на свой сервер, делать такую нарезку приходилось вручную (и это было больно)
Попробовал Typekit (сервис веб-шрифтов Adobe) и официально заявляю, что они — проклятье перформанса. Никогда не используйте их. Обходите их стороной. Если случайно закоммиттите их, напечатайте коммиты на бумаге и сожгите.
Что это
Typekit — это как Google Fonts, но от Adobe. Вы регистрируетесь, выбираете шрифты, получаете ссылку на стили, подключаете стили, радуетесь (наивные).
В чём проблема
Браузер не может нарисовать страницу, пока не загрузит все стили, которые есть на ней. А у Typekit самая антибыстрая реализация стилей, которую я когда-либо видел.
Когда вы выбираете шрифты, Typekit даёт вам ссылку на стили, которые нужно подключить — например, https://use.typekit.net/mzg2ufm.css. Эти стили живут на стороннем сервере (use.typekit.net), и это плохо — браузеру нужно потратить кучу времени на то, чтобы подключиться к этому серверу. Вот, например, в этом тесте стили со своего домена (запрос 2) скачиваются за 200 мс, а стили с домена Typekit — за 700. 500 мс мы просто устанавливаем соединение:
Что это
Typekit — это как Google Fonts, но от Adobe. Вы регистрируетесь, выбираете шрифты, получаете ссылку на стили, подключаете стили, радуетесь (наивные).
В чём проблема
Браузер не может нарисовать страницу, пока не загрузит все стили, которые есть на ней. А у Typekit самая антибыстрая реализация стилей, которую я когда-либо видел.
Когда вы выбираете шрифты, Typekit даёт вам ссылку на стили, которые нужно подключить — например, https://use.typekit.net/mzg2ufm.css. Эти стили живут на стороннем сервере (use.typekit.net), и это плохо — браузеру нужно потратить кучу времени на то, чтобы подключиться к этому серверу. Вот, например, в этом тесте стили со своего домена (запрос 2) скачиваются за 200 мс, а стили с домена Typekit — за 700. 500 мс мы просто устанавливаем соединение:
То есть браузер такой: «о, чётко, все
При этом — вы видите, откуда Typekit загружает другую таблицу стилей? С ещё одного стороннего домена. То есть браузер только что потратил 500 мс на подключение к use.typekit.net — и теперь тратит ещё 500 мс на подключение к p.typekit.net. Напоминаю, страница всё ещё не видна, потому что стили всё ещё не загрузились.
<link rel="stylesheet"> загрузились, можно отрендерить страницу». А Typekit ему такой: «пха, погоди, у меня тут ещё одни стили, не хочешь и их загрузить сначала?» И всё — вместо того, чтобы загрузить всё за раз, браузер загружает новые стили по второму кругу.При этом — вы видите, откуда Typekit загружает другую таблицу стилей? С ещё одного стороннего домена. То есть браузер только что потратил 500 мс на подключение к use.typekit.net — и теперь тратит ещё 500 мс на подключение к p.typekit.net. Напоминаю, страница всё ещё не видна, потому что стили всё ещё не загрузились.
И вот, наконец, браузер подключается к p.typekit.net, посылает запрос за стилями и спустя 700 мс наконец-то получает файл. Знаете, какое содержимое обнаруживается в этом файле?
ПУСТОЙ КОММЕНТАРИЙ.
ПУСТОЙ КОММЕНТАРИЙ.
То есть браузер держал страницу невидимой, тратил 500 мс на подключение к p.typekit.net и ещё 200 мс на ожидание файла — и всё это, чтобы скачать пустой комментарий. А всё потому, что Adobe таким образом собирает аналитику.¯\_(ツ)_/¯
Ну и, конечно, веб-шрифты не начинают загружаться, пока не загрузятся все стили:
Ну и, конечно, веб-шрифты не начинают загружаться, пока не загрузятся все стили:
И что с этим делать
Не используйте Typekit.
— Если те шрифты, которые вы подключаете через него, доступны и в Google Fonts, установите их — нет, не из Google Fonts, а из Fontsource
— Если шрифты недоступны, купите их на Fontspring (или попросите компанию купить — если вы никогда не просили, это проще, чем кажется) и подключите их через
Это сходу улучшит время первого рендера на сотни миллисекунд.
Не используйте Typekit.
— Если те шрифты, которые вы подключаете через него, доступны и в Google Fonts, установите их — нет, не из Google Fonts, а из Fontsource
— Если шрифты недоступны, купите их на Fontspring (или попросите компанию купить — если вы никогда не просили, это проще, чем кажется) и подключите их через
@font-faceЭто сходу улучшит время первого рендера на сотни миллисекунд.
Самый подробный гид про то, как Реакт работает внутри, эвер (ещё и от мейнтейнера Редакса) → https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-mostly-complete-guide-to-react-rendering-behavior/
Forwarded from Валя читает ишью
React Forget
Только что Xuan Huang (работал над Hermes) презентовал свой ресёрч React Without Memo.
Это компилятор, который позволит не использовать React.memo, генерируя код, который будет мемоизироваться автоматически. Пока что это закрытый эксперимент (React Forget это кодовое название) и не факт, что он завершится удачно.
Прикладываю 3 скриншота:
1. как выглядит мемоизированный код, который мы пишем сейчас;
2. как может выглядеть исходный код с использованием такого компилятора;
3. результат компиляции.
Ну и посмотрите сам доклад, он супер короткий: https://youtu.be/CzTXnOJj-uc?t=6906
P.S. Очень рад, что команда React двигается в эту сторону. Мне кажется, я до сих пор не понимаю когда мне нужен useCallback, а когда не особо, и, главное, как всё это правильно написать.
Только что Xuan Huang (работал над Hermes) презентовал свой ресёрч React Without Memo.
Это компилятор, который позволит не использовать React.memo, генерируя код, который будет мемоизироваться автоматически. Пока что это закрытый эксперимент (React Forget это кодовое название) и не факт, что он завершится удачно.
Прикладываю 3 скриншота:
1. как выглядит мемоизированный код, который мы пишем сейчас;
2. как может выглядеть исходный код с использованием такого компилятора;
3. результат компиляции.
Ну и посмотрите сам доклад, он супер короткий: https://youtu.be/CzTXnOJj-uc?t=6906
P.S. Очень рад, что команда React двигается в эту сторону. Мне кажется, я до сих пор не понимаю когда мне нужен useCallback, а когда не особо, и, главное, как всё это правильно написать.
Как получить GDE 🌟
В 2019-м я получил тайтл Google Developer Expert. Если вы хотели инструкцию, как это сделать и зачем это вообще, то вот :)
Что это
Google Developer Expert — это тайтл, который Google выдаёт разработчикам, которые засветились в какой-то сфере. Всего сфер 15, моя — Web Technologies (с подкатегорией Performance).
«Засветились в сфере» — это выступают, пишут и ведут про это соцсети.
В чём профит
— Узнаваемая медалька. С тайтлом GDE проще попадать докладчиком на конфы, привлекать внимание на собеседованиях и доказывать свой авторитет. Также можно хвастаться, что вы крутой/крутая ✨
— Доступ к Google-разработчикам. Например, меня добавили в слак и репозиторий, где я могу задавать вопросы напрямую разработчикам Chrome (я этим ни разу не пользовался ¯\_(ツ)_/¯). Также меня раз в месяц приглашают на созвоны, где Google-разработчики рассказывают, что нового в Chrome для веб-перформанса
— Редкие случайные бонусы. Один раз Google оплатил мне покупку веб-камеры, чтобы мне было проще вести вебинары
— Покрытие поездок (до ковида). До ковида Google покрывал билеты на самолёт и отели в городе, куда вы летели выступать на конференцию. Из-за ковида программу остановили 😔
Больше бенефитов никаких. Сотрудником Google вы не становитесь, деньги вам не платят.
В чём ответственность
— Чтобы оставаться GDE, придётся продолжать писать статьи и выступать с докладами. Раз в год вас проверяют на соответствие статуса GDE и, если вы не проходите, удаляют из программы. Как выглядит проверка — не знаю, для GDE она незаметна
— В соцсетях придётся написать «Opinions are my own»
Как понять, подходите ли вы
Если вы часто пишете в блог или выступаете про что-то, и вас читают в соцсетях, скорее всего, вы проходите.
Но у нас у всех же impostor syndrome, да? Если вы ходите податься на GDE, но сомневаетесь, проходите ли вы — спросите совета у меня (@iamakulov) или у другого GDE (ловите их на конференциях!).
Когда я подавался на GDE, у меня было
— 10-20 статей про веб-разработку (с большим количеством прочтений), часть из них — про перформанс
— 2-4 доклада
— И то ли 500, то ли 1000 подписчиков в Твитере
Как выглядит подача
Заполнить огромную форму → пройти два собеседования → подписать NDA → профит.
Я не помню, что меня спрашивали на собеседованиях (кроме вопроса «зачем мне тайтл GDE»). Собеседования описаны в гайде Google по подаче на GDE.
Как податься
Чтобы податься, нужно, чтобы вас зарефёррил существующий GDE. Прочтите гайд по подаче, напишите мне, и я зарефёррю :)
В 2019-м я получил тайтл Google Developer Expert. Если вы хотели инструкцию, как это сделать и зачем это вообще, то вот :)
Что это
Google Developer Expert — это тайтл, который Google выдаёт разработчикам, которые засветились в какой-то сфере. Всего сфер 15, моя — Web Technologies (с подкатегорией Performance).
«Засветились в сфере» — это выступают, пишут и ведут про это соцсети.
В чём профит
— Узнаваемая медалька. С тайтлом GDE проще попадать докладчиком на конфы, привлекать внимание на собеседованиях и доказывать свой авторитет. Также можно хвастаться, что вы крутой/крутая ✨
— Доступ к Google-разработчикам. Например, меня добавили в слак и репозиторий, где я могу задавать вопросы напрямую разработчикам Chrome (я этим ни разу не пользовался ¯\_(ツ)_/¯). Также меня раз в месяц приглашают на созвоны, где Google-разработчики рассказывают, что нового в Chrome для веб-перформанса
— Редкие случайные бонусы. Один раз Google оплатил мне покупку веб-камеры, чтобы мне было проще вести вебинары
— Покрытие поездок (до ковида). До ковида Google покрывал билеты на самолёт и отели в городе, куда вы летели выступать на конференцию. Из-за ковида программу остановили 😔
Больше бенефитов никаких. Сотрудником Google вы не становитесь, деньги вам не платят.
В чём ответственность
— Чтобы оставаться GDE, придётся продолжать писать статьи и выступать с докладами. Раз в год вас проверяют на соответствие статуса GDE и, если вы не проходите, удаляют из программы. Как выглядит проверка — не знаю, для GDE она незаметна
— В соцсетях придётся написать «Opinions are my own»
Как понять, подходите ли вы
Если вы часто пишете в блог или выступаете про что-то, и вас читают в соцсетях, скорее всего, вы проходите.
Но у нас у всех же impostor syndrome, да? Если вы ходите податься на GDE, но сомневаетесь, проходите ли вы — спросите совета у меня (@iamakulov) или у другого GDE (ловите их на конференциях!).
Когда я подавался на GDE, у меня было
— 10-20 статей про веб-разработку (с большим количеством прочтений), часть из них — про перформанс
— 2-4 доклада
— И то ли 500, то ли 1000 подписчиков в Твитере
Как выглядит подача
Заполнить огромную форму → пройти два собеседования → подписать NDA → профит.
Я не помню, что меня спрашивали на собеседованиях (кроме вопроса «зачем мне тайтл GDE»). Собеседования описаны в гайде Google по подаче на GDE.
Как податься
Чтобы податься, нужно, чтобы вас зарефёррил существующий GDE. Прочтите гайд по подаче, напишите мне, и я зарефёррю :)
Приходите смотреть, как Тимур Шемсединов сегодня валил меня вопросами по архитектуре: https://youtu.be/sNFPdfgax3Q
YouTube
Публичное собеседование: Чистый код, чистая нода, чистые функции / Тимур Шемсединов (Metarhia)
Понравилось видео и хочешь узнать что-то еще про Frontend Crew? Забирай весь плейлист на https://is.gd/kChYnl или купи билет на следующий сезон конференции https://is.gd/auKynm.
Подпишись на канал – каждую неделю мы выкладываем новые видео про то, как устроена…
Подпишись на канал – каждую неделю мы выкладываем новые видео про то, как устроена…
Рома Лютиков классно пишет про перформанс в Pitch (приложение для презентаций).
Про то, как в Pitch мониторят производительность: https://t.me/frontender_clj/116
Про декодинг изображений: https://t.me/frontender_clj/119
Про то, как в Pitch мониторят производительность: https://t.me/frontender_clj/116
Про декодинг изображений: https://t.me/frontender_clj/119
Telegram
Фронтенд и Кложура
О перфомансе во фронтенде
В Pitch мы нашли для себя неплохой механизм трекинга юзер ивентов, который используем в том числе локально для трейсинга различных аспектов приложения.
Пользовательские ивенты отслеживаются через RUM (Real User Monitoring) в DataDog.…
В Pitch мы нашли для себя неплохой механизм трекинга юзер ивентов, который используем в том числе локально для трейсинга различных аспектов приложения.
Пользовательские ивенты отслеживаются через RUM (Real User Monitoring) в DataDog.…