Тематическое исследование некоторых основных изменений, внесенных в Wix для улучшения производительности загрузки веб-сайтов для миллионов сайтов, открывая им путь к получению хороших оценок PageSpeed Insights и Core Web Vitals.
Благодаря использованию отраслевых стандартов, облачных провайдеров и возможностей CDN в сочетании с серьезным изменением среды выполнения нашего веб-сайта, процент сайтов Wix, достигших хороших 75-го процентиля по всем показателям Core Web Vitals, увеличился более чем втрое по сравнению с прошлым годом, согласно данным CruX и HTTPArchive .
Wix принял культуру, ориентированную на производительность, и дальнейшие улучшения будут продолжать распространяться среди пользователей. Сосредотачиваясь на ключевых показателях производительности, мы ожидаем, что число сайтов, соответствующих пороговым значениям Core Web Vitals, будет расти.
Обзор
Мир производительности невероятно сложен , со множеством переменных и тонкостей. Исследования показывают, что скорость сайта напрямую влияет на коэффициент конверсии и доходы бизнеса. В последние годы отрасль уделяет больше внимания прозрачности производительности и ускорению работы в Интернете . Начиная с мая 2021 года сигналы удобства страницы будут включаться в рейтинг Google Поиска.
Уникальная задача Wix — поддержка миллионов сайтов, некоторые из которых были созданы много лет назад и с тех пор не обновлялись. У нас есть различные инструменты и статьи, которые помогут нашим пользователям понять, что они могут сделать для анализа и улучшения производительности своих сайтов.
Wix — это управляемая среда, и не все находится в руках пользователя. Совместное использование общей инфраструктуры создает множество проблем для всех этих объектов, но также открывает возможности для серьезных улучшений по всем направлениям, то есть использования эффекта масштаба.
Говорим на обычном языке
Одна из основных трудностей с производительностью — найти общую терминологию для обсуждения различных аспектов пользовательского опыта, принимая во внимание как техническую, так и воспринимаемую производительность. Использование четко определенного, общего языка внутри организации позволило нам легко обсуждать и классифицировать различные технические части и компромиссы, прояснило наши отчеты о производительности и чрезвычайно помогло понять, на каких аспектах нам следует сосредоточиться в первую очередь.
Мы скорректировали все наши мониторинги и внутренние обсуждения, включив в них стандартные отраслевые показатели, такие как Web Vitals , которые включают в себя:
Сложность сайта и оценка производительности
Создать сайт, который загружается мгновенно, довольно легко, если вы сделаете его очень простым , используя только HTML, и обслуживаете его через CDN.
Однако реальность такова, что сайты становятся все более сложными и изощренными, работая больше как приложения, а не как документы, и поддерживая такие функции, как блоги, решения для электронной коммерции, пользовательский код и т. д.
Wix предлагает очень большое разнообразие шаблонов , позволяющих пользователям легко создавать сайты с множеством бизнес-возможностей. Эти дополнительные функции часто связаны с некоторыми затратами на производительность.
Путешествие
Вначале был HTML
Каждый раз, когда загружается веб-страница, она всегда начинается с первоначального запроса URL-адреса для получения HTML-документа. Этот HTML-ответ запускает все дополнительные клиентские запросы и логику браузера для запуска и отображения вашего сайта. Это самая важная часть загрузки страницы, поскольку ничего не происходит до тех пор, пока не придет начало ответа (известное как TTFB — время до первого байта).
Прошлое: рендеринг на стороне клиента (CSR)
При эксплуатации крупномасштабных систем всегда приходится учитывать компромиссы, такие как производительность, надежность и затраты. Еще несколько лет назад Wix использовал рендеринг на стороне клиента (CSR), при котором фактический HTML-контент генерировался с помощью JavaScript на стороне клиента (т. е. в браузере), что позволяло нам поддерживать большое количество сайтов без огромного бэкэнда. эксплуатационные расходы.
CSR позволила нам использовать общий HTML-документ, который был по сути пустым. Все, что он сделал, — это инициировал загрузку необходимого кода и данных, которые затем использовались для создания полного HTML-кода на клиентском устройстве.
Сегодня: рендеринг на стороне сервера (SSR)
Несколько лет назад мы перешли на рендеринг на стороне сервера (SSR), поскольку это было полезно как для SEO, так и для производительности, улучшая время видимости начальной страницы и обеспечивая лучшую индексацию для поисковых систем, которые не имеют полной поддержки запуска JavaScript.
Этот подход улучшил видимость, особенно на медленных устройствах и соединениях, и открыл возможности для дальнейшей оптимизации производительности. Однако это также означало, что на каждый запрос веб-страницы на лету генерировался уникальный HTML-ответ, что далеко не оптимально, особенно для сайтов с большим количеством просмотров.
Внедрение кэширования в нескольких местах
HTML-код каждого сайта был в основном статическим, но имел несколько оговорок:
- Оно часто меняется. Каждый раз, когда пользователь редактирует свой сайт или вносит изменения в данные сайта, например, в инвентарь магазина на веб-сайте.
- У него были определенные данные и файлы cookie, специфичные для посетителей , то есть два человека, посещающие один и тот же сайт, видели несколько разные HTML-коды. Например, для поддержки таких функций продуктов, как запоминание того, какие товары посетитель положил в корзину, или чат, который посетитель начал с компанией ранее, и многое другое.
- Не все страницы кэшируются. Например, страница с пользовательским кодом пользователя, которая отображает текущее время как часть документа, не подлежит кэшированию.
Первоначально мы использовали относительно безопасный подход к кэшированию HTML без данных о посетителях, а затем модифицировали только определенные части ответа HTML на лету для каждого посетителя и для каждого попадания в кэш.
Собственное решение CDN
Мы сделали это, развернув собственное решение: используя Varnish HTTP Cache для проксирования и кэширования, Kafka для сообщений о недействительности и службу на основе Scala/Netty, которая проксирует эти ответы HTML, но изменяет HTML и добавляет данные, специфичные для посетителей, и файлы cookie в кэшированный ответ.
Это решение позволило нам развернуть эти тонкие компоненты во многих других географических точках и в нескольких регионах поставщиков облачных услуг, которые разбросаны по всему миру. В 2019 году мы представили более 15 новых регионов и постепенно включили кеширование для более чем 90 % просмотров наших страниц, подпадающих под кеширование. Обслуживание сайтов из дополнительных мест уменьшило задержку в сети между клиентами и серверами, обслуживающими HTML-ответ, за счет приближения контента к посетителям веб-сайта.
Мы также начали кэшировать определенные ответы API, доступные только для чтения, используя то же решение и делая кеш недействительным при любом изменении содержимого сайта. Например, список сообщений блога на сайте кэшируется и становится недействительным при публикации/изменении сообщения.
Уменьшение сложностей
Внедрение кэширования существенно повысило производительность, в основном на этапах TTFB и FCP , а также повысило надежность за счет обслуживания контента из места, ближе к конечному пользователю.
Однако необходимость изменять HTML для каждого ответа приводила к ненужной сложности, устранение которой давало возможность дальнейшего улучшения производительности.
Кэширование браузера (и подготовка к CDN)
~ 13 %
HTML-запросы обслуживаются непосредственно из кеша браузера, что экономит большую часть трафика и сокращает время загрузки при повторных просмотрах.
Следующим шагом было полное удаление этих данных, специфичных для посетителей, из HTML и получение их из отдельной конечной точки, вызываемой клиентом для этой цели, после получения HTML.
Мы тщательно перенесли эти данные и файлы cookie на новую конечную точку, которая вызывается при каждой загрузке страницы, но возвращает небольшой JSON, который необходим только для процесса гидратации , чтобы обеспечить полную интерактивность страницы.
Это позволило нам включить кэширование HTML в браузере. Это означает, что браузеры теперь сохраняют ответ HTML для повторных посещений и вызывают сервер только для проверки того, что содержимое не изменилось. Это делается с помощью HTTP ETag , который по сути представляет собой идентификатор, присвоенный определенной версии HTML-ресурса. Если содержимое остается прежним, наши серверы отправляют клиенту ответ 304 Not Modified без тела.
Кроме того, это изменение означает, что наш HTML-код больше не ориентирован на посетителей и не содержит файлов cookie. Другими словами, его можно кэшировать где угодно, что открывает возможности для использования провайдеров CDN, которые имеют гораздо лучшее географическое присутствие в сотнях мест по всему миру.
DNS, SSL и HTTP/2
Благодаря включению кэширования время ожидания сократилось, а другие важные части первоначального соединения стали более существенными. Улучшение нашей сетевой инфраструктуры и мониторинга позволило нам улучшить время DNS, соединения и SSL.
HTTP/2 был включен для всех пользовательских доменов, что уменьшило как количество необходимых подключений, так и накладные расходы, связанные с каждым новым подключением. Это изменение было относительно легко развернуть, но при этом можно было воспользоваться преимуществами производительности и устойчивости , предоставляемыми HTTP/2.
Сжатие Brotli (по сравнению с gzip)
21 - 25 %
Уменьшение среднего размера передаваемого файла
Традиционно все наши файлы сжимались с использованием сжатия gzip , которое является наиболее распространенным вариантом сжатия HTML в Интернете. Этот протокол сжатия был впервые реализован почти 30 лет назад!
Новое сжатие Brotli обеспечивает улучшения сжатия практически без каких-либо компромиссов и постепенно становится все более популярным, как описано в ежегодной главе «Сжатие веб-альманаха». Некоторое время он поддерживается всеми основными браузерами .
Мы включили поддержку Brotli на наших прокси-серверах nginx в Edge для всех клиентов, которые ее поддерживают.
Переход на использование сжатия Brotli снизил средний размер передаваемых файлов на 21–25 % , что привело к снижению использования полосы пропускания и сокращению времени загрузки.
Сети доставки контента (CDN)
Динамический выбор CDN
В Wix мы всегда использовали CDN для обслуживания всего кода JavaScript и изображений на веб-сайтах пользователей.
Недавно мы интегрировали решение нашего DNS-провайдера, чтобы автоматически выбирать наиболее производительный CDN в соответствии с сетью и источником клиента. Это позволяет нам предоставлять статические файлы из наилучшего места для каждого посетителя и избегать проблем с доступностью в определенном CDN.
Скоро… пользовательские домены, обслуживаемые CDN
Последняя часть головоломки — это передача последней и самой важной части через CDN: HTML из пользовательского домена.
Как описано выше, мы создали собственное решение для кэширования и обслуживания результатов HTML и API, специфичных для сайта. Поддержание этого решения во многих новых регионах также сопряжено с эксплуатационными расходами, а добавление новых локаций становится процессом, которым нам необходимо управлять и постоянно оптимизировать.
В настоящее время мы интегрируемся с различными провайдерами CDN, чтобы поддерживать обслуживание всего сайта Wix непосредственно из мест CDN, чтобы улучшить распределение наших серверов по всему миру и, таким образом, еще больше сократить время отклика. Это проблема из-за большого количества обслуживаемых нами доменов, которые требуют завершения SSL на границе.
Интеграция с CDN делает веб-сайты Wix ближе, чем когда-либо, к клиенту, а также обеспечивает дополнительные улучшения в процессе загрузки, включая новые технологии, такие как HTTP/3, без дополнительных усилий с нашей стороны.
Несколько слов о мониторинге производительности
Если вы управляете сайтом Wix, вам, вероятно, интересно, как это отражается на результатах производительности вашего сайта Wix и как мы сравниваем его с другими платформами веб-сайтов.
Большая часть проделанной выше работы была развернута в прошлом году, а некоторые еще продолжаются.
Веб-альманах HTTPArchive недавно опубликовал издание 2020 года , которое включает в себя отличную главу, посвященную пользовательскому опыту CMS . Имейте в виду, что многие цифры, описанные в этой статье, относятся к середине 2020 года.
Мы с нетерпением ждем возможности увидеть обновленный отчет в 2021 году и активно отслеживаем отчеты CrUX для наших сайтов, а также наши внутренние показатели производительности.
Мы стремимся постоянно улучшать время загрузки и предоставлять нашим пользователям платформу, на которой они могут создавать сайты так, как они себе представляют, без ущерба для производительности.
DebugBear недавно выпустил очень интересный обзор производительности конструктора веб-сайтов , в котором затрагиваются некоторые области, упомянутые выше, и исследуется производительность очень простых сайтов, созданных на каждой платформе. Этот сайт был создан почти два года назад и с тех пор не менялся, но платформа постоянно совершенствуется, а вместе с ней и производительность сайта, в чем можно убедиться, просмотрев его данные за последние полтора года.
Заключение
Мы надеемся, что наш опыт вдохновит вас принять культуру, ориентированную на производительность, в вашей организации и что приведенная выше информация окажется полезной и применимой к вашей платформе или сайту.
Подводить итоги:
- Выберите набор показателей, которые вы сможете последовательно отслеживать с помощью инструментов, одобренных отраслью. Мы рекомендуем Core Web Vitals.
- Используйте кеширование браузера и CDN.
- Перейдите на HTTP/2 (или HTTP/3, если возможно).
- Используйте сжатие Brotli.
Благодарим вас за то, что узнали нашу историю, и мы приглашаем вас задавать вопросы, делиться идеями в Twitter и GitHub и присоединяться к обсуждению веб-производительности на ваших любимых каналах.