Ад - это чужой JavaScript.
Нет ничего более сокрушительного, чем создание красиво работающего веб-сайта только для того, чтобы он был заражен чумой сторонних скриптов, которые увеличивают вес каждой страницы и снижают скорость отклика, делая насмешкой над вашим хорошо продуманным бюджетом производительности.
Мое последнее понимание заключается в том, что создания производительного, доступного, адаптивного и масштабируемого веб-сайта недостаточно: мне также необходимо учитывать влияние сторонних скриптов.
Он начал процесс с перечисления сторонних скриптов. К сожалению, редко можно указать на одного единственного виновника - это совокупный эффект еще одного маяка, еще одного аналитического скрипта и еще одного инструмента A / B-тестирования, который в сумме дает дерьмо. Опыт, который согревает руки ваших пользователей, гарантируя, что ваш сайт постоянно разряжает их батарею.
На самом деле, как только что было сказано, что редко бывает один виновник, Adobe Tag Manager часто является корнем сторонних проблем. Вот и реклама. Это все равно, что открыть дверь в свой прекрасно обставленный дом мечты и пригласить стаю страдающих поносом слонов: «Пожалуйста, дерьмо, где хочешь».
Но даже более корректные сторонние скрипты могут выйти из-под контроля. Google Analytics настолько распространен, что даже не входит в список потенциально вредоносных сторонних скриптов. В целом, это довольно хорошо воспитанный гражданин из популяции сторонних скриптов на вашем сайте (вы знаете, не говоря уже о бизнес-модели капитализма слежки, которая позволяет вам использовать такой полезный инструмент бесплатно в обмен на отслеживание Google вашего посетителей сайта в Интернете и продажи информации, полученной на основе этих данных, рекламодателям).
Первоначальный скрипт аналитики, который вы асинхронно загружаете на свою страницу, не очень большой. Но в зависимости от того, как вы настроили свою учетную запись Google Analytics, это может быть только началом более длинной цепочки загрузок и обработчиков событий.
Эд недавно провел в Clearleft ланч-презентацию об использовании Google Analytics - он демонстрирует скромность, но действительно знает свое дело. Он следил за тем, чтобы все знали, как ставить цели - не вещи.
Насколько я понимаю, есть две основные категории целей: события и направления (есть еще длительности и страницы, но они похожи на направления). Вы используете события, чтобы ответить на такие вопросы, как Нажал ли пользователь эту кнопку? или Пользователь щелкнул по этому полю поиска?. Вы используете пункты назначения, чтобы отвечать на такие вопросы, как Пользователь зашел на эту страницу? или "Пользователь перешел с этой страницы?"
Вы можете добавить в аналитику своего сайта столько целей, сколько захотите. Это опьяняющее предложение. Проблема в том, что каждая цель, которую вы создаете, потенциально требует определенных затрат. Это невидимая цена. Он оплачивается пользователем в валюте JavaScript, отправляемой по сети (я бы хотел, чтобы интерфейс администратора Google Analytics был больше похож на старый интерфейс для Google Fonts, где каждый дополнительный файл, который вы добавляли, буквально толкал иглу выше на циферблате).
Мне кажется, что для целей, основанных на событиях, обязательно потребуется больше JavaScript, чтобы улавливать эти клики и запускать эту информацию. Цели, основанные на пункте назначения, должны иметь возможность получать всю необходимую информацию при регулярном перемещении по страницам.
Итак, у меня есть гипотеза. Я думаю, что цели, основанные на назначении, менее вредны для производительности, чем цели, основанные на событиях. Я вполне могу ошибаться в этом, и если я ошибаюсь, пожалуйста, дайте мне знать.
Имея в виду эту гипотезу и пока я не узнаю обратного, у меня есть два практических правила, которые я могу предложить, когда дело доходит до использования Google Analytics:
- Постарайтесь свести количество голов к минимуму.
- Если вы должны создать цель, отдавайте предпочтение направлениям, а не событиям.
Изначально это было размещено на моем собственном сайте.
