Прежде чем оптимизировать сторонние теги, убедитесь, что эти скрипты по-прежнему нужны на вашем сайте.
Сторонние скрипты или «теги» могут быть источником проблем с производительностью вашего сайта и, следовательно, объектом оптимизации. Однако прежде чем приступить к оптимизации добавленных вами тегов, убедитесь, что вы не оптимизируете те теги, которые вам даже не нужны. В этой статье показано, как оценивать запросы на новые теги, а также управлять существующими и проверять их.
При обсуждении сторонних тегов разговор часто быстро переходит к проблемам производительности, упуская из виду основы того, какова «основная» роль этих тегов. Они предоставляют широкий спектр полезных функций, делая Интернет более динамичным, интерактивным и взаимосвязанным . Однако сторонние теги могут добавляться разными командами в организации, и со временем о них часто забывают. Люди уходят, контракты истекают или результаты уже получены, но команды так и не выходят на связь, чтобы удалить сценарии.
Прежде чем вы начнете думать о выполнении стороннего сценария тегов или о том, какие теги можно отложить, отложенно загрузить или предварительно подключить с технической точки зрения, есть возможность управлять тем, какие теги добавляются на сайт/страницу с организационной точки зрения. . Общая проблема веб-сайтов, работа которых замедляется из-за огромного количества сторонних тегов, заключается в том, что эта часть веб-сайта не принадлежит одному человеку или команде и, следовательно, остается незамеченной. Нет ничего более неприятного, чем оптимизировать ваш веб-сайт, довольный производительностью в промежуточной среде, но в рабочей среде скорость снижается из-за добавляемых тегов. Внедрение «процесса проверки» сторонних тегов может помочь предотвратить это за счет создания рабочего процесса, который создает межфункциональную подотчетность и ответственность за эти теги.
Способ проверки сторонних тегов зависит исключительно от организации, ее структуры и текущих процессов. Это может быть так же просто, как наличие одной команды, которая будет управлять и выступать в качестве привратника для анализа тегов перед их добавлением. Или более продвинутый и формальный вариант, например, предоставив командам форму для отправки запросов на тег. Это может потребовать контекста с точки зрения того, почему он должен быть на веб-сайте, как долго он должен присутствовать и какую пользу это принесет бизнесу.
Процесс управления тегами
Независимо от того, как вы решите проверять теги внутри своей организации, следующие этапы следует рассматривать как часть жизненного цикла тега.
Согласие
Прежде чем добавлять какой-либо тег на страницу, убедитесь, что он был тщательно проверен командой юристов, чтобы убедиться, что он соответствует всем требованиям соответствия для его присутствия. Это может включать проверку соответствия тега Общему регламенту ЕС по защите данных (GDPR) и Закону Калифорнии о конфиденциальности потребителей (CCPA) .
Это очень важно: если на этом этапе возникают какие-либо сомнения, их необходимо устранить, прежде чем оценивать тег с точки зрения производительности.
Необходимый
Второй шаг — задаться вопросом, нужен ли на странице конкретный тег. Рассмотрите следующие вопросы для обсуждения:
- Активно ли используется тег? Если нет, то можно ли его удалить?
- Если тег загружается по всему сайту, необходимо ли это? Например, если мы анализируем набор A/B-тестирования, а вы в настоящее время тестируете только целевые страницы, можем ли мы удалить тег только на этом типе страниц?
- Можем ли мы добавить к этому дополнительную логику, можем ли мы определить, существует ли живой A/B-тест? Если да, разрешите добавление тега, но если нет, убедитесь, что он отсутствует.
Владение
Наличие четкого лица или команды в качестве владельца тега помогает активно отслеживать теги. Обычно это тот, кто добавил тег. Наличие правопреемника рядом с тегом гарантирует, что в будущем можно будет проводить проверки и аудиты, чтобы повторно проверить, требуется ли тег.
Цель
Четвертый шаг начинается с создания межфункциональной подотчетности и ответственности, гарантируя, что люди понимают, почему тег добавляется на страницу. Важно обеспечить межфункциональное понимание того, что каждый тег приносит на веб-сайт и почему он используется. Например, если тег записывает действия сеанса пользователя, чтобы обеспечить персонализацию, все ли команды знают, почему это должно присутствовать?
Кроме того, проводились ли какие-либо дискуссии о компромиссе между коммерцией и производительностью? Если существует тег, который считается «обязательным», поскольку он приносит доход, был ли проведен анализ потенциального дохода, потерянного из-за регрессии скорости?
Обзор
Пятый, последний и, пожалуй, самый важный шаг — обеспечить регулярную проверку тегов. Это должно зависеть от размера веб-сайта, количества тегов на сайте и времени их обработки (например, еженедельно, ежемесячно, ежеквартально). К этому следует относиться так же, как к оптимизации других ресурсов веб-сайта (JS, CSS, изображения и т. д.) и регулярно проверять его. Невыполнение проверки может привести к «раздутому» менеджеру тегов, что замедляет работу страниц. Возврат к производительности без снижения требуемой функциональности на странице может оказаться сложной задачей.
В ходе проверки вы получите окончательный список тегов, которые классифицируются по мере необходимости для конкретной страницы. На этом этапе вы можете углубиться в подходы к технической оптимизации . Это также открывает возможность определить количество тегов в этом окончательном списке в рамках бюджета производительности , который можно отслеживать в Lighthouse CI и включать в постановку целей, ориентированных на производительность. Например:
Если мы будем придерживаться <5 тегов на наших целевых страницах вместе с собственным оптимизированным JS, мы уверены , что общее время блокировки (TBT) может достичь «хорошего» значения в основных веб-показателях .