От автора: персонализированное и A / B тестирование производительности сайта и его контента сегодня является общей характеристикой многих веб-сайтов, поскольку оно может помочь командам улучшить конверсию и вовлеченность. Однако в последние годы мы видели, как многие сайты перемещали эти рабочие процессы динамического контента со стороны сервера на сторону клиента, чтобы упростить работу групп маркетинга и UX при меньшей поддержке со стороны разработчиков. К сожалению, этот переход на JS на стороне клиента может сильно повлиять на производительность.
Старая проблема переключения и ожидания
Напомним стандартную реализацию этого шаблона: сервер доставляет полезный HTML-контент вместе с некоторым JavaScript, который будет блокировать отрисовку страницы во время загрузки и парсинга скриптов. Этот период блокировки является первой проблемой производительности рабочего процесса, но за ним следует еще более вопиющий: после выполнения скрипта он удалит часть содержимого со страницы и заменит ее новым содержимым. Этот новый контент может быть более ориентирован на конкретного пользователя, но время и сложность его доставки могут означать длительные задержки для пользователей. По иронии судьбы, возможность увеличить конверсию с помощью этих инструментов может достигаться за счет возможности некоторых пользователей использовать сайт вообще.
Этот шаблон приводит к такому уникальному влиянию на загрузку страниц, что на конференции Perf.Now() на прошлой неделе я придумал новый немного метафизический показатель производительности под названием «Второй значимый контент», он появляется намного позже удобного показателя Первый значимый контент (или отображение ), который обозначает время, через которое страница может использоваться.
Визуальная временная шкала шаблона имеет тенденцию выглядеть следующим образом:
Этот шаблон может возникнуть на ранее быстром, оптимизированном сайте и сделать его (хе, извините) мучительно медленным; мы видели сайты со страницами, время до первого взаимодействия которых составляло 4 или 5 секунд на обычном телефоне и в обычной сети, а затем им внезапно стало требоваться 12 секунд, чтобы их просто можно было начать использовать.
Одной из причин этой задержки является то, что сегодня обработка JavaScript на смартфонах занимает много времени, даже если он загружается быстро. Например, среднестатистическому новому смартфону в настоящее время требуется 2 секунды для обработки 200 КБ сжатого JavaScript, что как раз и соответствует размеру JavaScript для A / B теста, используемого на сайте, который я сейчас тестирую. Другая причина задержки заключается в том, что иногда эти скрипты запускают дополнительные блокирующие запросы на сервер, пока пользователь ожидает, вводя еще больше циклов загрузки и парсинга скриптов.
Способы оптимизации
Этот шаблон стал настолько широко распространенным в наши дни, что теперь кажется, проще сделать быстрый сайт, чем поддерживать эту скорость. Так что мы можем с этим поделать?
A / B тесты только при повторных посещениях: Сначала мы можем порекомендовать владельцам сайтов использовать эти инструменты на стороне клиента в менее критических ситуациях, чтобы они наносили меньше ущерба. Например, они могли бы не изменять содержимое для посетителей, впервые посещающих сайт, а вместо этого просто предварительно загружать скрипты, чтобы они кэшировались и были готовы к использованию при последующих просмотрах страницы. Конечно, кэширование скриптов поможет только со временем загрузки . Время, которое тратится на фактическое выполнение скриптов после загрузки, является другой проблемной.
Предварительная загрузка необходимого. Использование элементов link[rel=preload] в head HTML-документа для предварительной загрузки скриптов, которые будут запрошены позднее, может значительно сократить время загрузки. Еще раз, это не решит вопрос задержек, возникающих при парсинге и запуске скриптов после их загрузки, но может сэкономить секунды при предварительной загрузке.
A / B контент только ниже первого сгиба и (в идеале) откладывание скриптов: Мы могли бы рекомендовать, чтобы динамический контент использовался только для частей страницы, которые находятся вне области просмотра, когда страница загружается впервые — глубоко внизу страницы. Таким образом пользователи могут не видеть, что происходит мерцание контента. Если этот вариант использования возможен, стоит также подумать, можно ли ссылаться на блокирующие скрипты и загружать их позже, возможно, непосредственно перед тем фрагментом контента, который они используют.
Переход к тестированию на стороне сервера: И наконец, в идеале, мы можем рекомендовать сайтам заменять инструменты контента на стороне клиента на те, которые работают на стороне сервера, чтобы тяжелая обработка выполнялась до того, как контент будет доставлен в браузер. Многие инструменты для персонализации и A / B-тестирования предлагают альтернативы на стороне сервера, и мы должны подтолкнуть владельцев сайтов к рассмотрению этих инструментов.
В следующем посте я подробно расскажу о подходе, с которым мы экспериментировали в последнее время — он дает нам преимущества серверного подхода с гибкостью работы с JavaScript. Оставайтесь на связи!
Автор: Scott
Источник: https://www.filamentgroup.com/
Редакция: Команда webformyself.