Распространенные паттерны связанные с производительностью

Сколько статики мы можем генерировать?

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

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

В статье Building Partially Hydrated, Progressively Enhanced Static Websites Маркус Оберленер (Markus Oberlehner) показывает, как создавать веб-сайты с помощью генератора статики SPA, сохраняя при этом небольшой размер JavaScript бандла. В качестве инструментов Маркус использует Eleventy и Preact. В статье рассказывается, как их настроить, добавить частичную и ленивую гидрацию, настроить Babel для Preact и собрать Preact при помощи Rollup.
Сейчас, когда JAMStack используется на крупных сайтах, появился ещё один важный показатель производительности: время сборки. Создание тысяч страниц при каждом деплое может занять несколько минут. Отличное решение в таких случаях — инкрементальные сборки в Gatsby (улучшают время сборки в 60 раз). Они могут интегрироваться с популярными CMS: WordPress, Contentful, Drupal, Netlify CMS и другие.

Инкрементальная статическая регенерация с Next.js. (Источник: Prisma.io) (Увеличить)
Кроме того, Next. js анонсировал ahead-of-time and incremental static generation. Эта техника позволяет добавлять новые статические страницы на лету и обновлять существующие страницы уже после их создания (перерендеривая страницы в фоновом режиме по мере поступления трафика).

Нужно ещё проще? Посмотрите выступление Николы Готэ (Nicola Goutay) Eleventy, Alpine and Tailwind: towards a lightweight Jamstack, где он объясняет различия между CSR, SSR и всем остальным (смотрите GitHub репозиторий с примерами).
Различные фреймворки по-разному влияют на производительность и требуют разных стратегий оптимизации. Вы должны четко понимать все особенности фреймворка, с которым будете работать. При создании веб-приложения изучите шаблон PRPL и архитектуру app shell. Идея довольно проста: отправьте минимальное количество кода, нужного для первого рендера вашей активной страницы, затем используйте сервис-воркер для кэширования ресурсов и ленивой загрузки остального контента.

App shell— это минимальный HTML, CSS и JavaScript, поддерживающий пользовательский интерфейс.

Вы ускорили ваше API?

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

Время ответа от API-сервера добавляется к времени рендеринга вашей страницы. При этом, если вам понадобится сделать несколько запросов к API, то время каждого запроса добавится к времени рендеринга. В результате вы можете получить избыточные данные, которые не нужны для начальной отрисовки вашей страницы

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

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

Если вы хотите погрузиться в тему GraphQL и решить некоторые проблемы производительности, Виталий Фридман рекомендует обратиться к этим статьям:
Разница между REST и GraphQL, на примере Redux + REST слева vs Apollo + GraphQL справа. (Источник фото: Hacker Noon) (Увеличить)

Будете ли вы использовать AMP или Instant articles?

Возможно, в своём проекте вы будете использовать AMP от Google, Instant articles от Facebook или Apple News. Хорошей производительности можно добиться и без них. AMP — это надежный фреймворк с бесплатным CDN, Instant Articles повышают вашу видимость на Facebook и улучшают производительность. Всё зависит от приоритетов и стратегии вашей компании.

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

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

По крайней мере, так было раньше. Поскольку AMP больше не является обязательным требованием для попадания в Top Stories от Google, издатели, скорее всего, перейдут от AMP к традиционному стеку. Тем не менее, вы можете создавать прогрессивные веб-AMP, используя AMP в качестве источника данных для PWA. Но и здесь есть свои недостатки. Разработчики закрытых экосистем могут создавать и поддерживать отдельную версию контента, а в случае Instant Articles и Apple News ещё и без реальных URL-адресов.

Выбирайте CDN правильно

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

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

Кэти Хемпениус (Katie Hempenius) написала прекрасное руководство по CDN. Оно дает представление о том, как выбрать и настроить CDN. Виталий Фридман рекомендует максимально агрессивно кэшировать контент и использовать Brotli, TLS 1.3, HTTP/2 и HTTP/3.
Примечание: согласно исследованиям Патрика Минана (Patrick Meenan) и Энди Дэвиса (Andy Davies), приоритизация HTTP/2 плохо работает во многих CDN, поэтому будьте осторожны при выборе! Подробнее об этом — в докладе Патрика Минана о «Приоритезации HTTP/2».
Если прямо сейчас вы в процессе выбора CDN, Виталий Фридман советует изучить эти источники:
  • CDN Comparison. Сравнительная таблица CDN для Cloudfront, Azure, KeyCDN, Fastly, Verizon, Stackpach, Akamai и многих других.
  • CDN Perf. Измеряет скорость разных CDN, собирая и анализируя более 300 млн тестов ежедневно. Результаты основаны на данных RUM от пользователей по всему миру. Также посмотрите DNS Performance comparison и Cloud Peformance Comparison.
  • CDN Planet Guides. Тематические обзоры CDN (сжатие, предварительная выборка и др.).
  • Web Almanac: CDN Adoption and Usage. Информация о ведущих поставщиках CDN, их управлении RTT и TLS, времени согласования TLS, внедрении HTTP/2 и других (к сожалению, данные только за 2019 год).

CDNPerf измеряет скорость запросов для CDN, собирая и анализируя 300 миллионов тестов каждый день. (Увеличить)