Front-End Performance 2021: определение среды

Это руководство было любезно поддержано нашими друзьями из LogRocket, службы, которая сочетает в себе мониторинг производительности внешнего интерфейса , воспроизведение сеанса и аналитику продукта, чтобы помочь вам повысить качество обслуживания клиентов. LogRocket отслеживает ключевые показатели, в т.ч. DOM завершен, время до первого байта, задержка первого ввода, использование клиентского ЦП и памяти. Получите бесплатную пробную версию LogRocket сегодня.

Оглавление

1. Подготовка: планирование и показатели
2. Постановка реалистичных целей
3. Определение среды
4. Оптимизация активов
5. Оптимизация сборки
6. Оптимизация доставки
7. Сеть, HTTP/2, HTTP/3
8. Тестирование и мониторинг
9. Быстрые победы
10. Все на одной странице
11. Скачать контрольный список (PDF, Apple Pages, MS Word)
12. Подпишитесь на нашу рассылку по электронной почте, чтобы не пропустить следующие руководства.

Определение среды

1. Выберите и настройте инструменты сборки.
   Не обращайте слишком много внимания на то, что в наши дни считается крутым. Придерживайтесь своей среды для сборки, будь то Grunt, Gulp, Webpack, Parcel или комбинация инструментов. Пока вы получаете нужные результаты и у вас нет проблем с поддержанием процесса сборки, у вас все в порядке.

   Среди инструментов сборки Rollup продолжает набирать обороты, как и Snowpack, но Webpack, кажется, является наиболее признанным, с буквально сотнями доступных плагинов для оптимизации размера ваших сборок. Следите за дорожной картой Webpack 2021.

   Одной из наиболее примечательных стратегий, появившихся в последнее время, является дробное разбиение на фрагменты с помощью Webpack в Next.js и Gatsby для минимизации дублирования кода. По умолчанию модули, которые не являются общими в каждой точке входа, могут быть запрошены для маршрутов, которые их не используют. В конечном итоге это становится накладными расходами, поскольку загружается больше кода, чем необходимо. Благодаря гранулированному фрагментированию в Next.js мы можем использовать файл манифеста сборки на стороне сервера, чтобы определить, какие выходные фрагменты используются разными точками входа.

   

   С помощью SplitChunksPlugin несколько разделенных фрагментов создаются в зависимости от ряда условий, чтобы предотвратить выборку дублированного кода по нескольким маршрутам. Это улучшает время загрузки страницы и кэширование во время навигации. Поставляется в Next.js 9.2 и в Gatsby v2.20.7.

   Однако начать работу с Webpack может быть сложно. Итак, если вы хотите погрузиться в Webpack, есть несколько отличных ресурсов:

   • Документация по Webpack — очевидно — является хорошей отправной точкой, как и Webpack — The Confusing Bits от Raja Rao и Annotated Webpack Config от Andrew Welch.
   • У Шона Ларкина есть бесплатный курс по Webpack: The Core Concepts, а Джеффри Уэй выпустил фантастический бесплатный курс по Webpack для всех. Оба они являются отличным введением для погружения в Webpack.
   • Webpack Fundamentals — это очень подробный 4-часовой курс с Шоном Ларкиным, выпущенный FrontendMasters.
   • Примеры Webpack содержат сотни готовых к использованию конфигураций Webpack, классифицированных по темам и целям. Бонус: есть также конфигуратор конфигурации Webpack, который генерирует базовый файл конфигурации.
   • awesome-webpack — это список полезных ресурсов, библиотек и инструментов Webpack, включая статьи, видео, курсы, книги и примеры для Angular, React и проектов, не зависящих от фреймворка.
   • Путь к быстрой сборке производственных активов с помощью Webpack — это тематическое исследование Etsy о том, как команда перешла от использования системы сборки JavaScript на основе RequireJS к использованию Webpack и как они оптимизировали свои сборки, управляя более чем 13 200 активами в среднем за 4 минуты .
   • Советы по производительности Webpack — золотая ветка Ивана Акулова, содержащая множество советов, ориентированных на производительность, в том числе те, которые специально ориентированы на Webpack.
   • awesome-webpack-perf — это золотой репозиторий GitHub с полезными инструментами и плагинами Webpack для повышения производительности. Также поддерживается Иваном Акуловым.

1. Используйте прогрессивное улучшение по умолчанию.
   Тем не менее, по прошествии стольких лет, сохранение прогрессивного улучшения в качестве руководящего принципа вашей интерфейсной архитектуры и развертывания является беспроигрышным вариантом. Сначала спроектируйте и создайте основной интерфейс, а затем улучшите его с помощью расширенных функций для совместимых браузеров, создавая устойчивые интерфейсы. Если ваш веб-сайт работает быстро на медленной машине с плохим экраном в плохом браузере в неоптимальной сети, то он будет работать быстрее только на быстрой машине с хорошим браузером в приличной сети.

   На самом деле, с адаптивным обслуживанием модулей мы, кажется, выводим прогрессивное улучшение на новый уровень, предоставляя «упрощенные» базовые возможности для недорогих устройств и добавляя более сложные функции для устройств высокого класса. Прогрессивное улучшение вряд ли исчезнет в ближайшее время.

2. Выберите сильный базовый уровень производительности.
   С таким количеством неизвестных факторов, влияющих на загрузку — сеть, тепловое регулирование, удаление кеша, сторонние сценарии, шаблоны блокировки синтаксического анализатора, дисковый ввод-вывод, задержка IPC, установленные расширения, антивирусное программное обеспечение и брандмауэры, фоновые задачи ЦП, ограничения оборудования и памяти, различия в кэшировании L2/L3, RTTS — JavaScript имеет самую большую стоимость опыта, рядом с веб-шрифтами, блокирующими рендеринг по умолчанию, и изображениями, часто потребляющими слишком много памяти. Поскольку узкие места в производительности переходят от сервера к клиенту, мы, как разработчики, должны рассмотреть все эти неизвестные гораздо подробнее.

   С бюджетом в 170 КБ, который уже содержит критический путь HTML/CSS/JavaScript, маршрутизатор, управление состоянием, утилиты, фреймворк и логику приложения, мы должны тщательно изучить стоимость передачи по сети, время синтаксического анализа/компиляции и стоимость времени выполнения. рамки по нашему выбору. К счастью, за последние несколько лет мы наблюдаем значительный прогресс в том, насколько быстро браузеры могут анализировать и компилировать скрипты. Тем не менее, выполнение JavaScript по-прежнему является основным узким местом, поэтому пристальное внимание к времени выполнения скрипта и сети может иметь большое значение.

   Тим Кадлек провел фантастическое исследование производительности современных фреймворков и резюмировал их в статье «Фреймворки JavaScript имеют свою цену». Мы часто говорим о влиянии автономных фреймворков, но, как отмечает Тим, на практике нередко используется несколько фреймворков . Возможно, это старая версия jQuery, которая постепенно переносится на современный фреймворк, а также несколько устаревших приложений, использующих более старую версию Angular. Поэтому более разумно изучить совокупную стоимость байтов JavaScript и время выполнения ЦП, которые могут легко сделать пользовательский опыт практически непригодным для использования даже на устройствах высокого класса.

   Как правило, современные фреймворки не отдают приоритет менее мощным устройствам , поэтому производительность на телефоне и на настольном компьютере часто сильно различается. Согласно исследованиям, сайты с React или Angular тратят на ЦП больше времени, чем другие (что, конечно, не обязательно означает, что React требует больше ресурсов ЦП, чем Vue.js).

   По словам Тима, очевидно одно: «если вы используете фреймворк для создания своего сайта, вы идете на компромисс с точки зрения начальной производительности — даже в лучшем из сценариев».

1. Оцените фреймворки и зависимости.
   Теперь не каждому проекту нужен фреймворк, и не каждая страница одностраничного приложения должна загружать фреймворк. В случае с Netflix «удаление React, нескольких библиотек и соответствующего кода приложения со стороны клиента уменьшило общий объем JavaScript более чем на 200 КБ, что привело к сокращению времени до интерактивности Netflix более чем на 50% для домашней страницы, на которой не выполнен вход. ." Затем команда использовала время, проведенное пользователями на целевой странице, для предварительной выборки React для последующих страниц, на которые, скорее всего, попадут пользователи (подробности читайте далее).

   Так что, если вы вообще удалите существующую структуру на критических страницах? С Gatsby вы можете проверить gatsby-plugin-no-javascript, который удаляет все файлы JavaScript, созданные Gatsby, из статических файлов HTML. В Vercel вы также можете разрешить отключение исполняемого JavaScript для определенных страниц (экспериментально).

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

   Данные показывают, что по умолчанию фреймворки довольно дороги: 58,6% страниц React содержат более 1 МБ JavaScript, а 36% загрузок страниц Vue.js имеют первую отрисовку содержимого менее 1,5 с. Согласно исследованию Анкура Сетхи, «ваше приложение React никогда не будет загружаться быстрее, чем за 1,1 секунды на среднем телефоне в Индии, независимо от того, насколько вы его оптимизируете. Для загрузки вашего приложения Angular всегда требуется не менее 2,7 секунды». пользователям вашего приложения Vue нужно будет подождать не менее 1 секунды, прежде чем они смогут начать его использовать». Возможно, вы в любом случае не ориентируетесь на Индию как на основной рынок, но пользователи, заходящие на ваш сайт с неоптимальными сетевыми условиями, будут иметь сопоставимый опыт.

   Конечно , можно делать SPA быстро, но они не быстры из коробки, поэтому нам нужно учитывать время и усилия, необходимые для их быстрого создания и поддержания . Вероятно, будет проще выбрать облегченную базовую стоимость производительности на раннем этапе.

   Итак, как мы выбираем фреймворк ? Прежде чем выбирать вариант, рекомендуется учитывать как минимум общую стоимость размера + начальное время выполнения; легкие варианты, такие как Preact, Inferno, Vue, Svelte, Alpine или Polymer, могут отлично справиться с работой. Размер вашего базового плана будет определять ограничения для кода вашего приложения.

   Как отмечает Себ Маркбейдж, хороший способ измерить начальные затраты для фреймворков — сначала отобразить представление, затем удалить его, а затем снова отрендерить, поскольку это может сказать вам, как масштабируется фреймворк. Первый рендер имеет тенденцию разогревать кучу лениво скомпилированного кода, что может принести пользу более крупному дереву при его масштабировании. Второй рендеринг в основном представляет собой эмуляцию того, как повторное использование кода на странице влияет на характеристики производительности по мере усложнения страницы.

   Вы можете даже оценить своих кандидатов (или любую библиотеку JavaScript в целом) по 12-балльной системе оценки Саши Грейфа, изучив функции, доступность, стабильность, производительность, экосистему пакетов , сообщество, кривую обучения, документацию, инструменты, послужной список. , команда, совместимость, безопасность например.

   

   Вы также можете полагаться на данные, собранные в Интернете за более длительный период времени. Например, Perf Track отслеживает производительность платформы в масштабе, показывая агрегированные по источнику баллы Core Web Vitals для веб-сайтов, созданных на Angular, React, Vue, Polymer, Preact, Ember, Svelte и AMP. Вы даже можете указать и сравнить веб-сайты, созданные с помощью Gatsby, Next.js или Create React App, а также веб-сайты, созданные с помощью Nuxt.js (Vue) или Sapper (Svelte).

   Хорошей отправной точкой является выбор хорошего стека по умолчанию для вашего приложения. Gatsby (React), Next.js (React), Vuepress (Vue), Preact CLI и PWA Starter Kit обеспечивают разумные значения по умолчанию для быстрой загрузки из коробки на среднее мобильное оборудование. Также ознакомьтесь с руководством по производительности для React и Angular, относящимся к фреймворку web.dev ( спасибо, Филипп! ).

   И, возможно, вы могли бы применить немного более свежий подход к созданию одностраничных приложений в целом — Turbolinks, библиотеку JavaScript размером 15 КБ, которая использует HTML вместо JSON для отображения представлений. Поэтому, когда вы переходите по ссылке, Turbolinks автоматически извлекает страницу, заменяет ее <body> и объединяет ее <head> , и все это без затрат на полную загрузку страницы. Вы можете проверить краткие подробности и полную документацию о стеке (Hotwire).

1. Рендеринг на стороне клиента или рендеринг на стороне сервера? Обе!
   Это довольно горячий разговор. Окончательным подходом было бы настроить своего рода прогрессивную загрузку: использовать рендеринг на стороне сервера, чтобы получить быструю первую контекстную отрисовку, но также включить минимально необходимый JavaScript, чтобы время до интерактивности оставалось близким к первой контентной отрисовке. Если JavaScript появляется слишком поздно после FCP, браузер блокирует основной поток при анализе, компиляции и выполнении поздно обнаруженного JavaScript, тем самым ограничивая интерактивность сайта или приложения.

   Чтобы этого избежать, всегда разбивайте выполнение функций на отдельные асинхронные задачи и по возможности используйте requestIdleCallback . Рассмотрите ленивую загрузку частей пользовательского интерфейса с помощью поддержки динамического import() WebPack, избегая затрат на загрузку, синтаксический анализ и компиляцию до тех пор, пока они действительно не понадобятся пользователям ( спасибо, Адди! ).

   Как упоминалось выше, время до интерактивности (TTI) сообщает нам время между навигацией и интерактивностью. В деталях метрика определяется путем просмотра первого пятисекундного окна после рендеринга начального контента, в котором ни одна задача JavaScript не занимает более 50 мс ( длительные задачи ). Если возникает задача более 50 мс, поиск пятисекундного окна начинается заново. В результате браузер сначала предположит, что он достиг Interactive , просто для того, чтобы переключиться на Frozen , чтобы в конечном итоге переключиться обратно на Interactive .

   Как только мы достигли Interactive , мы можем — либо по требованию, либо, когда позволяет время — загружать второстепенные части приложения. К сожалению, как заметил Пол Льюис, фреймворки обычно не имеют простой концепции приоритета, которую можно было бы донести до разработчиков, и, следовательно, прогрессивную загрузку нелегко реализовать с большинством библиотек и фреймворков.

   Тем не менее, мы добираемся туда. В наши дни есть несколько вариантов, которые мы можем изучить, и Хусейн Джирдех и Джейсон Миллер предоставили отличный обзор этих вариантов в своем докладе о рендеринге в Интернете и в статье Джейсона и Эдди о современных интерфейсных архитектурах. Обзор ниже основан на их звездной работе.

   • Полный рендеринг на стороне сервера (SSR)
     В классическом SSR, таком как WordPress, все запросы обрабатываются исключительно на сервере. Запрошенный контент возвращается в виде готовой HTML-страницы, и браузеры могут сразу ее отображать. Следовательно, SSR-приложения не могут использовать, например, DOM API. Разрыв между First Contentful Paint и Time to Interactive обычно невелик, и страница может отображаться сразу же, как HTML передается в браузер.

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

   • Статическая визуализация
     Мы создаем продукт как одностраничное приложение, но все страницы предварительно визуализируются в статический HTML с минимальным JavaScript в качестве шага сборки. Это означает, что при статическом рендеринге мы заранее создаем отдельные HTML-файлы для каждого возможного URL -адреса, что не многие приложения могут себе позволить. Но поскольку HTML-код для страницы не нужно генерировать на лету, мы можем добиться неизменно быстрого времени до первого байта. Таким образом, мы можем быстро отобразить целевую страницу, а затем выполнить предварительную выборку SPA-фреймворка для последующих страниц. Netflix применил этот подход, снизив загрузку и время до взаимодействия на 50%.

   • Рендеринг на стороне сервера с (ре)гидратацией (универсальный рендеринг, SSR + CSR)
     Мы можем попытаться использовать лучшее из обоих подходов — SSR и CSR. С добавлением гидратации HTML-страница, возвращаемая с сервера, также содержит сценарий, который загружает полноценное клиентское приложение. В идеале добиться быстрой первой отрисовки содержимого (например, SSR), а затем продолжить рендеринг с (ре)гидратацией. К сожалению, это бывает редко. Чаще страница выглядит готовой, но не может реагировать на действия пользователя, вызывая гневные клики и отказы.

     С React мы можем использовать модуль ReactDOMServer на сервере Node, таком как Express, а затем вызвать метод renderToString для отображения компонентов верхнего уровня в виде статической строки HTML.

     С Vue.js мы можем использовать vue-server-renderer для рендеринга экземпляра Vue в HTML с помощью renderToString . В Angular мы можем использовать @nguniversal для превращения клиентских запросов в HTML-страницы, полностью отображаемые сервером. Кроме того, с помощью Next.js (React) или Nuxt.js (Vue) можно получить полностью серверную визуализацию.

     У подхода есть свои минусы. В результате мы получаем полную гибкость клиентских приложений, обеспечивая при этом более быстрый рендеринг на стороне сервера, но в итоге мы получаем более длительный разрыв между First Contentful Paint и Time To Interactive и увеличенную задержку первого ввода. Регидратация стоит очень дорого, и обычно одной этой стратегии недостаточно, поскольку она сильно задерживает время до взаимодействия.

     
   • Потоковая передача на стороне сервера с прогрессивной гидратацией (SSR + CSR)
     Чтобы свести к минимуму разрыв между Time To Interactive и First Contentful Paint, мы обрабатываем несколько запросов одновременно и отправляем контент частями по мере его создания. Таким образом, нам не нужно ждать полной строки HTML, прежде чем отправлять содержимое в браузер, и, следовательно, улучшить время до первого байта.

     В React вместо renderToString() мы можем использовать renderToNodeStream() для передачи ответа и отправки HTML по частям. В Vue мы можем использовать renderToStream(), который может передаваться по конвейеру и передаваться в потоковом режиме. С React Suspense мы также можем использовать асинхронный рендеринг для этой цели.

     На стороне клиента вместо загрузки всего приложения сразу мы загружаем компоненты постепенно . Разделы приложений сначала разбиваются на отдельные сценарии с разделением кода, а затем постепенно (в порядке наших приоритетов) гидратируются. Фактически, мы можем сначала гидратировать критически важные компоненты, а остальные можно гидратировать позже. Затем роль рендеринга на стороне клиента и на стороне сервера может быть определена по-разному для каждого компонента. Затем мы также можем отложить гидратацию некоторых компонентов до тех пор, пока они не появятся в поле зрения или потребуются для взаимодействия с пользователем, или пока браузер не будет бездействовать.

     Для Vue Маркус Оберленер опубликовал руководство по сокращению времени до взаимодействия приложений SSR с помощью гидратации при взаимодействии с пользователем, а также vue-lazy-hydration, плагина ранней стадии, который включает гидратацию компонентов при видимости или конкретном взаимодействии с пользователем. Команда Angular работает над прогрессивным увлажнением с помощью Ivy Universal. Вы также можете реализовать частичную гидратацию с помощью Preact и Next.js.

   • Трисоморфный рендеринг
     Имея сервис-воркеров, мы можем использовать рендеринг потокового сервера для начальных/не-JS-навигаций, а затем заставлять сервис-воркер рендерить HTML для навигации после его установки. В этом случае сервисный работник выполняет предварительную визуализацию контента и включает навигацию в стиле SPA для визуализации новых представлений в том же сеансе. Хорошо работает, когда вы можете совместно использовать один и тот же код шаблонов и маршрутизации между сервером, клиентской страницей и работником службы.

   

   • CSR с предварительным рендерингом
     Предварительный рендеринг похож на рендеринг на стороне сервера, но вместо динамического рендеринга страниц на сервере мы визуализируем приложение в статический HTML во время сборки. В то время как статические страницы полностью интерактивны без большого количества клиентского JavaScript, предварительный рендеринг работает по-другому . По сути, он фиксирует начальное состояние клиентского приложения в виде статического HTML во время сборки, в то время как с предварительным рендерингом приложение должно быть загружено на клиенте, чтобы страницы были интерактивными.

     С помощью Next.js мы можем использовать статический экспорт HTML, предварительно отрендерив приложение в статический HTML. В Gatsby, генераторе статических сайтов с открытым исходным кодом, использующем React, во время сборки используется метод renderToStaticMarkup вместо метода renderToString , при этом основной фрагмент JS предварительно загружается, а будущие маршруты предварительно выбираются без атрибутов DOM, которые не нужны для простых статических страниц.

     Для Vue мы можем использовать Vuepress для достижения той же цели. Вы также можете использовать prerender-loader с Webpack. Navi также обеспечивает статический рендеринг.

     В результате улучшается время до первого байта и первая отрисовка по содержанию, и мы уменьшаем разрыв между временем до интерактивности и первой отрисовкой по содержанию. Мы не можем использовать этот подход, если ожидается, что контент сильно изменится. Кроме того, все URL-адреса должны быть известны заранее, чтобы сгенерировать все страницы. Таким образом, некоторые компоненты могут быть отрисованы с использованием предварительной отрисовки, но если нам нужно что-то динамическое, мы должны полагаться на приложение для получения содержимого.

   • Полный рендеринг на стороне клиента (CSR)
     Вся логика, рендеринг и загрузка выполняются на клиенте. Результатом обычно является огромный разрыв между Time To Interactive и First Contentful Paint. В результате приложения часто чувствуют себя вялыми , поскольку все приложение должно быть загружено на клиенте, чтобы отобразить что-либо.

     Поскольку у JavaScript есть издержки производительности, поскольку объем JavaScript растет вместе с приложением, агрессивное разделение кода и отсрочка JavaScript будут абсолютно необходимы для сдерживания влияния JavaScript. В таких случаях рендеринг на стороне сервера обычно будет лучшим подходом, если не требуется много интерактивности. Если это не вариант, рассмотрите возможность использования модели оболочки приложения.

     В общем, SSR быстрее, чем CSR. Тем не менее, это довольно частая реализация для многих приложений.

   Итак, на стороне клиента или на стороне сервера? В целом рекомендуется ограничить использование полностью клиентских фреймворков страницами, которые в них абсолютно необходимы. Для продвинутых приложений также не рекомендуется полагаться только на рендеринг на стороне сервера. И рендеринг на сервере, и рендеринг на клиенте — это катастрофа, если они сделаны плохо.

   Независимо от того, склоняетесь ли вы к CSR или SSR, убедитесь, что вы рендерите важные пиксели как можно скорее и минимизируете разрыв между этим рендерингом и временем до интерактивности. Подумайте о предварительном рендеринге, если ваши страницы не сильно меняются, и по возможности отложите загрузку фреймворков. Потоковая передача HTML фрагментами с рендерингом на стороне сервера и внедрение прогрессивной гидратации для рендеринга на стороне клиента — и гидратация при видимости, взаимодействии или во время простоя, чтобы получить лучшее из обоих миров.

1. Сколько мы можем обслуживать статически?
   Независимо от того, работаете ли вы над большим приложением или небольшим сайтом, стоит подумать о том, какой контент можно обслуживать статически из CDN (т. е. стека JAM), а не генерировать динамически «на лету». Даже если у вас есть тысячи продуктов и сотни фильтров с множеством вариантов персонализации, вы все равно можете статически обслуживать важные целевые страницы и отделять эти страницы от выбранной вами структуры.

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

   В книге «Создание частично гидратированных статических веб-сайтов с прогрессивным улучшением» Маркус Оберленер показывает, как создавать веб-сайты с помощью генератора статических сайтов и SPA, добиваясь прогрессивного улучшения и минимального размера пакета JavaScript. Маркус использует Eleventy и Preact в качестве своих инструментов и показывает, как настроить инструменты, добавить частичную гидратацию, ленивую гидратацию, файл записи клиента, настроить Babel для Preact и связать Preact с Rollup — от начала до конца.

   В наши дни, когда JAMStack используется на крупных сайтах, появился новый фактор производительности: время сборки . На самом деле, создание даже тысяч страниц при каждом новом развертывании может занять несколько минут, поэтому обещают увидеть инкрементные сборки в Gatsby, которые сократят время сборки в 60 раз благодаря интеграции с популярными решениями CMS, такими как WordPress, Contentful, Drupal, Netlify CMS. и другие.

   

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

   Нужен еще более легкий подход? В своем выступлении об Eleventy, Alpine и Tailwind: на пути к облегченному Jamstack Никола Гутей объясняет различия между CSR, SSR и всем, что между ними, и показывает, как использовать более легкий подход — вместе с репозиторием GitHub, который показывает этот подход. на практике.

2. Рассмотрите возможность использования шаблона PRPL и архитектуры оболочки приложения.
   Различные фреймворки по-разному влияют на производительность и требуют разных стратегий оптимизации, поэтому вы должны четко понимать все азы фреймворка, на который будете полагаться. При создании веб-приложения изучите шаблон PRPL и архитектуру оболочки приложения. Идея довольно проста: добавьте минимальный код, необходимый для интерактивности, чтобы начальный маршрут отображался быстро, затем используйте сервис-воркер для кэширования и предварительного кэширования ресурсов, а затем лениво загружайте нужные вам маршруты асинхронно.

1. Вы оптимизировали производительность своих API?
   API — это каналы связи, с помощью которых приложение может предоставлять данные внутренним и сторонним приложениям через конечные точки . При разработке и создании API нам нужен разумный протокол для обеспечения связи между сервером и сторонними запросами. Передача репрезентативного состояния ( REST ) — это хорошо зарекомендовавший себя логичный выбор: он определяет набор ограничений, которым следуют разработчики, чтобы сделать контент доступным производительным, надежным и масштабируемым образом. Веб-службы, соответствующие ограничениям REST, называются веб-службами RESTful .

   Как и в случае со старыми добрыми HTTP-запросами, когда данные извлекаются из API, любая задержка в ответе сервера будет распространяться на конечного пользователя, что приведет к задержке рендеринга . Когда ресурс хочет получить некоторые данные из API, ему нужно будет запросить данные из соответствующей конечной точки. Компоненту, отображающему данные из нескольких ресурсов, например статьи с комментариями и авторскими фотографиями в каждом комментарии, может потребоваться несколько обращений к серверу, чтобы получить все данные, прежде чем их можно будет отобразить. Кроме того, количество данных, возвращаемых через REST, часто превышает то, что необходимо для рендеринга этого компонента.

   Если многим ресурсам требуются данные из API, API может стать узким местом в производительности. GraphQL предлагает эффективное решение этих проблем. По сути, GraphQL — это язык запросов для вашего API и среда выполнения на стороне сервера для выполнения запросов с использованием системы типов, которую вы определяете для своих данных. В отличие от REST, GraphQL может извлекать все данные в одном запросе , и ответ будет именно таким, какой требуется, без избыточной или недостаточной выборки данных, как это обычно происходит с REST.

   Кроме того, поскольку GraphQL использует схему (метаданные, которые сообщают, как структурированы данные), он уже может организовывать данные в предпочтительную структуру, поэтому, например, с GraphQL мы могли бы удалить код JavaScript, используемый для управления состоянием, создавая более чистый код приложения, который быстрее работает на клиенте.

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

   • Учебник по GraphQL: зачем нам нужен новый вид API, Эрик Баер,
   • Учебник по GraphQL: эволюция дизайна API, Эрик Баер,
   • Разработка сервера GraphQL для оптимальной производительности Леонардо Лосовица,
   • Производительность GraphQL объяснил Войцех Троцкий.

1. Будете ли вы использовать AMP или Instant Articles?
   В зависимости от приоритетов и стратегии вашей организации вы можете рассмотреть возможность использования Google AMP, Instant Articles от Facebook или Apple News от Apple. Вы можете добиться хорошей производительности и без них, но AMP обеспечивает надежную основу производительности с бесплатной сетью доставки контента (CDN), а Instant Articles повысит вашу видимость и производительность на Facebook.

   Казалось бы очевидным преимуществом этих технологий для пользователей является гарантированная производительность , поэтому иногда они могут даже предпочесть AMP-/Apple News/Instant Pages-ссылки «обычным» и потенциально раздутым страницам. Для веб-сайтов с большим количеством контента, которые имеют дело с большим количеством стороннего контента, эти параметры потенциально могут значительно ускорить время рендеринга.

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

   Выгода для владельца веб-сайта очевидна: возможность обнаружения этих форматов на соответствующих платформах и повышенная видимость в поисковых системах.

   Ну, по крайней мере, так было раньше. Поскольку AMP больше не является обязательным требованием для Top Stories , издатели могут вместо этого перейти от AMP к традиционному стеку ( спасибо, Барри! ).

   Тем не менее, вы также можете создавать прогрессивные веб-AMP, повторно используя AMP в качестве источника данных для вашего PWA. Недостатки? Очевидно, что присутствие в огороженном саду дает разработчикам возможность создавать и поддерживать отдельную версию своего контента, а в случае Instant Articles и Apple News без фактических URL-адресов (спасибо, Эдди, Джереми!) .

2. Выбирайте CDN с умом.
   Как упоминалось выше, в зависимости от того, сколько у вас динамических данных, вы можете «аутсорсить» некоторую часть контента генератору статических сайтов, отправляя его в CDN и обслуживая оттуда статическую версию, тем самым избегая запросов к сервер. Фактически, некоторые из этих генераторов на самом деле являются компиляторами веб-сайтов с множеством автоматических оптимизаций, предоставляемых из коробки. По мере того как компиляторы со временем добавляют оптимизацию, скомпилированный вывод со временем становится меньше и быстрее.

   Обратите внимание, что CDN также могут обслуживать (и разгружать) динамический контент. Таким образом, ограничивать CDN статическими активами не обязательно. Дважды проверьте, выполняет ли ваш CDN сжатие и преобразование (например, оптимизацию изображений и изменение размера на периферии), обеспечивают ли они поддержку рабочих серверов, A/B-тестирование, а также периферийные включения, которые объединяют статические и динамические части страниц. на границе CDN (т. е. ближайший к пользователю сервер) и другие задачи. Также проверьте, поддерживает ли ваш CDN HTTP через QUIC (HTTP/3).

   Кэти Хемпениус написала фантастическое руководство по CDN, в котором рассказывается о том, как выбрать хорошую CDN , как ее настроить, а также обо всех мелочах, которые следует учитывать при ее оценке. Как правило, рекомендуется максимально агрессивно кэшировать содержимое и включать функции повышения производительности CDN, такие как Brotli, TLS 1.3, HTTP/2 и HTTP/3.

   Примечание . Согласно исследованиям Патрика Минана и Энди Дэвиса, приоритизация HTTP/2 фактически нарушена во многих CDN, поэтому будьте осторожны при выборе CDN. У Патрика есть более подробная информация в его докладе о приоритизации HTTP/2 ( спасибо, Барри! ).

   

   При выборе CDN вы можете использовать эти сравнительные сайты с подробным обзором их функций:

   • Сравнение CDN, матрица сравнения CDN для Cloudfront, Aazure, KeyCDN, Fastly, Verizon, Stackpach, Akamai и многих других.
   • CDN Perf измеряет скорость запросов для CDN, собирая и анализируя 300 миллионов тестов каждый день, причем все результаты основаны на данных RUM от пользователей со всего мира. Также проверьте сравнение производительности DNS и сравнение производительности облака.
   • CDN Planet Guides предоставляет обзор CDN по конкретным темам, таким как Serve Stale, Purge, Origin Shield, Prefetch и Compression.
   • Веб-альманах: принятие и использование CDN предоставляет информацию о ведущих поставщиках CDN, их управлении RTT и TLS, времени согласования TLS, внедрении HTTP/2 и многом другом. (К сожалению, данные только за 2019 год).

Оглавление

1. Подготовка: планирование и показатели
2. Постановка реалистичных целей
3. Определение среды
4. Оптимизация активов
5. Оптимизация сборки
6. Оптимизация доставки
7. Сеть, HTTP/2, HTTP/3
8. Тестирование и мониторинг
9. Быстрые победы
10. Все на одной странице
11. Скачать контрольный список (PDF, Apple Pages, MS Word)
12. Подпишитесь на нашу рассылку по электронной почте, чтобы не пропустить следующие руководства.