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

Этот пост был вдохновлен моим знакомством с популярным сборщиком модулей Webpack — еще одной из тех (многих) вещей, которым вас не учат на курсах по программированию.

Точнее, я начал с желания изучить Webpack, а затем обнаружил, что спускаюсь в кроличью нору Почему, например:

  1. Зачем нам вообще нужен Webpack? О, это для объединения модулей…
  2. Зачем нам вообще нужно объединение модулей? О, это помогает сократить время загрузки нашей страницы…
  3. Почему объединение в пакеты улучшает время загрузки страницы? Во-первых, если мы объединяем небольшие модули кода в большие пакеты, мы можем уменьшить количество запросов, которые мы отправляем на сервер, что, как правило, лучше для производительности. Кроме того, умное разделение кода также означает, что мы можем выбрать загрузку основных пакетов сначала, чтобы наша страница работала быстро, а оставшиеся пакеты загружаются лениво после этого.

В этот момент я понял, что ничего не знаю об основах веб-производительности, и это фактически мешало моему мастерству в React (замене любого другого внешнего интерфейса). Например, я понятия не имел, в чем смысл React.lazy() или React.Suspense, поэтому просто никогда их не использовал.

Это был не лучший подход, потому что, чтобы быть хорошим веб-разработчиком, вам, вероятно, нужно заботиться о хорошей веб-производительности. В конце концов, какой смысл создавать сайт с помощью React/Angular/Vue, если каждый клик загружается вечно?

Итак, вот что я узнал о веб-производительности

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

  • Работа в Интернете поддается объективному измерению, но также является воспринимаемым опытом — например, мы можем использовать отложенную загрузку, чтобы сделать наши веб-сайты интерактивными до загрузки всего содержимого. Это создает у пользователей впечатление, что веб-сайт адаптивен. В связи с этим я настоятельно рекомендую эту известную статью Якоба Нильсена о принципах дизайна взаимодействия с пользователем.
  • Общие показатели веб-производительности – первая осмысленная отрисовка, максимально насыщенная отрисовка, время до интерактивности и т. д. PageSpeed ​​от Google очень полезен для создания отчетов об эффективности.
  • Рекомендуемое время веб-производительности — очевидно, это что-то?! В частности, я подумал, что стремление обеспечивать обратную связь с пользователем в течение 50–200 мс является хорошим ориентиром.
  • Критический путь рендеринга — фундаментальная концепция, которую нам необходимо понять, чтобы оптимизировать время до первого рендеринга.

Заключение

Мой обзор веб-производительности ни в коем случае не был исчерпывающим, но его было достаточно, чтобы я по-новому оценил функции, связанные с производительностью, в таких фреймворках, как React и NextJS. Я надеюсь, что это было полезно и для вас! Теперь я могу вернуться к изучению Webpack по гороху — погодите, а зачем нам загрузчик Babel?

😉