как невозможно подключить свои скрипты к теме
Как и где подключить скрипт?
Доброго времени суток. 🙂
Данная статья не столько материал о котором хочется поговорить, а универсальная инструкция для многих статей на моем сайте. Хочу один раз расписать подробно, как подключать скрипт на сайте, где это можно сделать и как лучше. Если вы на моем сайте бываете часто и используете материалы из статей, то замечали, что в каждой статье где идет упоминание о добавлении скриптов, я постоянно пишу о том где их вставить. Мне надоело повторять одно и то же, легче будет добавлять ссылку на эту статью. У меня уже была схожая статья Как подключить скрипты и где лучше это сделать. Тогда я не полностью раскрыл данный вопрос. Удалять старую статью или переписывать не хочу, поэтому создам новую. Не будем затягивать и приступим.
Где подключать скрипты?
Если у вас имеется элемент для сайта, который использует javascript, jQuery и его библиотеки, то их нужно будет подключить. Обычно все подключается в шапке сайта перед закрывающимся head или в подвал перед закрывающимсяbody. Тут стоит выбирать вам и опираться на задачу и обстоятельства.
Есть скрипты, которые попросту не работают в шапке или наоборот в подвале. Возможно на вашем сайте все вызовы скриптов уже размещены в подвале для улучшения скорости загрузки или вы следовали указанием сервисов на подобии PageSpeed Insights. Если это так, то естественно и новые скрипты тоже размещаете в подвале.
Хочу отдельно упомянуть про WordPress. В шапке подключайте свои скрипты после wp_head();. В подвале имеется функция wp_footer();, все подключения после нее. В зависимости от настроек эти функции выводят библиотеку jQuery и другие скрипты WordPress, после которых и следует подключать свои. хотя если у вас простенький javascript код, то можно и не придерживаться этого правила.
Как подключать скрипт?
По этому принципу подключается и библиотека jQuery. Обычно это выглядит так:
Следует учесть, что нельзя подключать несколько библиотеки jQuery. Если это сделано уже ранее, то не следует повторять. Внимательно просматривайте код на наличие такого подключения. Чаще всего, в системах управления сайтами, типа WordPress, библиотека подключена по умолчанию. Не всегда можно найти в файлах такую строку, нужно смотреть через браузер. Опять, в том же WordPress библиотека выводится в wp_head(); или wp_footer();, о которых я упомянул выше, в зависимости от настроек.
Библиотека jQuery по коду должна быть первой, а скрипты что нуждаются в ней должны быть размещены после нее. Простые java скрипты этому правилу не подчиняются, только jQuery. Запомните это правило. Оно поможет избежать вам в будущем множества проблем.
Но если он занимает большой объем, занимать им место на странице, как по мне не разумно и не удобно.
В один файл можно размещать множество скриптов. Лично я часто пользуюсь таким методом. Причем одновременно можно добавлять как и обычный javascript, так и jQuery скрипты.
После того, как скрипт или скрипты в файл добавлены, его подключаем так же как и библиотеку. С помощью тегов указывая путь к файлу. Файл, естественно заливаете на сайт в папку с другими файлами сайта. В какую именно, решать вам, в зависимости от того какая система у вас или как вы захотите. Например, вы создали рядом с файлом где HTML код, папку с названием js и в нее поместили наш файл.
Теперь просто после библиотеки в подвале или в шапке, смотря где вы размещаете добавляете строку с подключением нашего файла.
Подключение скриптов в WordPress
Разберем функцию по-порядку:
Помните я в начале говорил о том, что можно настроить вывод в подвале и в шапке. Данная функция по умолчанию выведет скрипт в шапке. Чтобы добавить в подвал нужно добавить в строку с подключением еще один параметр.
Если Вы захотите подключить 2 файла то функция будет такой:
Так же, с помощью такой функции можно подключать и библиотеку jQuery. Но есть один момент. По умолчанию WordPress уже использует библиотеку, поэтому вторую так просто нельзя подключать, нужно отключить старую.
лично я всегда отключаю встроенную библиотеку и подключаю от Google. Делается это следующим образом. В примере будет и переподключение библиотеки и подключение файла со скриптом, чтобы вы видели как это выглядит и понимали что все просто и по тому же принципу.
Возможно покажется сложным, но если разобраться и понять суть все станет ясно, легко и просто. Такое подключение для WordPress является правильным и наилучшим.
Сжатие скриптов
Несмотря на то, как вы подключили скрипт, вы можете облегчит его загрузку браузером. Обычно скрипт имеет вот такой вид:
Согласитесь, читать такой скрипт легко и удобно, понятно и не напряжно. Но если такой понятный скрипт занимает 100 строк. В нем тысячи пробелов, комментариев и прочего ненужного хлама, что не влияет на скрипт. Но браузеру нужно немного больше времени чтобы его загрузить. А если таких скриптов больше десятка? Нагрузка на сайт увеличивается и время его загрузки тоже. А если скрипт станет таким?
Не плохо правда? Всего одна длинная строка, но намного меньше по объему. Читать такой скрипт сложнее, но если вам не нужно его постоянно править, вы настроили его один раз и все, то такое сжатие принесет только плюсы. Чтобы сделать это, можно помучатся вручную или воспользоваться любым сервисом по сжатию java скриптов.
После сжатия и правильного подключения ваши скрипты будут отлично работать и минимально нагружать сайт.
На этом все, спасибо за внимание. 🙂
Если Вам был полезным мой труд, можете финансово поддержать сайт или отключить блокировщик рекламы, что займет 2 минуты 🙂
Как добавить пользовательский JavaScript на WordPress-сайт
Существует несколько способов добавления пользовательского JavaScript в WordPress. В этом руководстве мы рассмотрим каждый из них.
Добавление пользовательского JavaScript на WordPress
Чтобы добавить собственный JavaScript-код на WordPress- сайт, нужно использовать:
Чего не нужно делать
Самый простой способ добавить пользовательский скрипт в WordPress – это использовать тег
1. Использование плагина для добавления пользовательского JavaScript-кода
Использование плагина рекомендуется, если:
1.1. Плагины для редактирования header.php и footer.php
Первый вариант – использование плагина для редактирования шаблонов header.php и footer.php темы оформления WordPress. Если нужно добавить скрипты, которые загружаются до содержимого страницы, необходимо отредактировать шаблон шапки. Скрипты, которые загружаются после содержимого веб-страницы, добавляются в шаблон футера.
Плагин Insert Headers and Footers позволяет редактировать шаблоны хедера и футера. Он добавляет скрипты к хукам действий wp_head или wp_footer соответственно.
1.2. Плагины для добавления пользовательского JavaScript
1.3. Скрипты, специфичные для плагинов
Создатели популярных JavaScript-библиотек часто публикуют бесплатные плагины в репозитории WordPress.org для добавления своих скриптов. Подобные плагины поставляется со встроенными параметрами конфигурации для конкретной JavaScript-библиотеки.
Например, плагин GA Google Analytics позволяет интегрировать Google Analytics на сайт прямо из панели администрирования WordPress. Он поставляется со встроенными функциями, специфичными для скрипта Google Analytics.
2. Редактирование файла functions.php дочерней темы оформления
Также можно использовать встроенные в WordPress функции и хуки действий. В этом случае необходимо отредактировать файл functions.php и вручную загрузить скрипт на используемый сервер. Также желательно создать дочернюю тему оформления для сохранения ваших настроек.
Затем добавьте PHP-код, который ставит в очередь или выводит пользовательский JavaScript-код, в functions.php дочерней темы оформления. Это можно сделать через меню Внешний вид> Редактор тем в панели администрирования WordPress.
2.1. Добавление собственных скриптов в очередь с помощью функции wp_enqueue_script()
С помощью wp_enqueue_script() можно добавить собственный JavaScript в шаблоны хедера и футера. По умолчанию функция размещает скрипты в раздел страницы.
Чтобы добавить скрипт в хедер, нужно определить собственный дескриптор (‘custom’ в примере, приведенном ниже) и путь к скрипту. А также использовать функцию get_stylesheet_directory_uri() для получения URI каталога дочерней темы оформления.
Функция WordPress wp_enqueue_script() и хук действия wp_enqueue_scripts имеют почти одинаковые имена. Но это разные методы.
Функцию wp_enqueue_script() можно использовать для добавления пользовательского JavaScript-кода в шаблон футера. Для этого потребуется определить дополнительные параметры:
Для добавления зависимости, которая не зарегистрирована в WordPress, нужно использовать собственный дескриптор. Но перед этим необходимо зарегистрировать его и поставить зависимость в очередь с помощью функции wp_enqueue_script().
2.2. Вывод встроенного скрипта с помощью хуков действий wp_head и wp_footer
Пример использования хука wp_head для вывода скрипта в шаблоне хедера:
Пример использования wp_footer для вывода скрипт в шаблоне футера:
Скрипты, добавленные с помощью этих хуков, не будут загружаться в панели администрирования и на странице входа. Чтобы запускать пользовательские скрипты в панели администрирования WordPress, необходимо использовать хуки действия admin_head и admin_footer в функции add_action().
Заключение
Использование плагина для добавления пользовательского JavaScript является рекомендуемым методом. Эти плагины гарантируют, что скрипты будут загружаться в правильном порядке.
Дайте знать, что вы думаете по этой теме статьи в комментариях. Мы крайне благодарны вам за ваши комментарии, дизлайки, отклики, подписки, лайки!
Как подключить javascript на странице или посте wordpress
В процессе работы с WordPress, иногда, возникает необходимость подключить javascript в посте или странице WP. Некоторые горе программисты решают эту задачу подключая все файлы яваскрипт в шапке или просто запихнув код в пост, если первый вариант невозможный. Сегодня я расскажу и покажу вам несколько вариантов подключения любого кода javascript на wordpress странице.
Зачем нужно у вордпрессе подключать javascript на странице:
Подключаем wordpress javascript на странице через шорткод
Делается это довольно просто:
1) Открываем файл темы functions.php.
2) В самом начале файла создаем шорткод вот таким способом:
Если нужно подключить отдельный файл javascript:
или же вот такой код, если вам нужно вывести код в странице WordPress:
Вместо alert(«пример»); можно писать свой яваскрипт код, только следите чтоб кавычки были правильные и не конфликтовали. Все ‘ надо закрывать в /’ для яваскрипта внутри этого ПХП.
Более подробно о том, как создать шорткод wordpress (откроется в новом окне) читайте по ссылке.
Многие программисты могут меня упрекнуть, что мол это не самый хороший код для вызова wordpress javascript на странице, но он рабочий. Далее я расскажу вам другие способы добавления яваскрипт.
Добавляем javascript на страницу wordpress через wp_enqueue_script
к менюФункция wp_enqueue_script идеально подходит для подключения яваскрипта к теме, но немножко туговато для подключения к отдельной странице, но все же с точки зрения правильности кода, такой вариант более правильный чем первый.
Подробные параметры функции wp_enqueue_script (откроется в новом окне) можно прочитать перейдя по ссылке, сейчас я вам покажу пример для отдельной страницы и отдельного поста.
Предположим, что нам нужно подключить javascript файл «myScript.js» для страницы с идентификатором 15, которому для работы нужна библиотека jQuery:
1) Открываем файл темы functions.php.
2) В самое начало записываем код:
3) Сохраняем, и заливаем на сервер, теперь на странице 15 будет вызываться файл под именем myScript.js
4) Если нам потребуется подключить этот javascript для поста wordpress с ид 21, то код будет такого плана:
Подключение wordpress javascript на странице в файле header.php
1) Открываем файл темы header.php.
2) Перед закрывающимся тегом пишем:
или вот так, если нам нужно подключить файл до поста:
или вот так если нужно до категории:
3) Если вам нужно не подключить код, а просто вывести его, то выглядеть это будет по аналогии с пунктом 2:
На этом у меня все, надеюсь эти 3 реализации подключения javascript на странице wordpress помогут вам правильно подключить код или вывести его.
Я не большой любитель WP, но вот заказали на нем сайт, да и сам подумал, что для человека никогда не администрировавшего сайт, cms’ка пойдет. У меня такой вопрос: можно ли массивом добавлять идентификаторы страниц? Влияет ли вложенность страниц на срабатывание скрипта? Буду рад ответу.
Извините, пропустил.
К сожалению статьи про Ajax у меня нет. Частично можно посмотреть в самописной форме обратной связи https://help-wp.ru/obratnaya-svyaz-wordpress-bez-plagina/ она на технологии аякс сделана.
Да, сложно с wp после october, сортировки медиафайлов нет, bootstrap 4 меню, чтобы полностью вывести с depth 3 знатно покрасноглазил (в итоге поменял разметку), для подключения конкретных скриптов и стилей нужен массив с id поста, иное почему-то у меня не прокатило, плагины на бесплатном хостинге, либо отказываются работать, либо работают корректно только их платные версии, в общем я повеселился, поседел и запил)) Благо уже на финишной прямой. Успехов!
Самый простой вариант забросить подключение в шорткод вот так:
(там же можно и основную инфу написать что должен делать и возвращать шорткод через return)
ДД, а чем плох первый способ?
ДД, чем плох 1й способ? Вроде наоборот, скрипт грузится только на нужных страницах. Если таких не много, то это положительно сказывается на работе сайта.
Добрый.
Плох тем, что так делать запрещают стандарты ВП. Еще плох тем что нельзя подключить плагин чтоб он оптимизировал скрипт, сжал и так далее этот код. Также при таком подключении не получится перенести этот скрипт в футер, код будет болтаться посреди текста. Еще могут возникнуть проблемы если нужны разные версии jquery когда посредине сайта нужна первая версия в в начале и конце вторая. Нюансов много, просто о них вспоминают только когда надо что то серьезное поправить, а оно не получается 🙂
P.S. Во втором способе скрипт тоже грузится только там где нужно.
Спасибо.
Но как во втором случае сделать подключения без указания номера страницы?
1. Страниц,постов может быть несколько. (Как указать несколько страниц/постов?)
2.Каждый раз лезть в код чтобы добавить новый номер не совсем удобно.
Со страницами наверное можно использовать специально созданный шаблон, и подключать только в нем.
Только как модифицировать if чтобы проверялся шаблон?
Хотя наверное можно и с постами и с использовать мета поле, скажем script = 1, тогда подключается скрипт.
Так правильно будет?
Вы видимо хотите подключить в самом шорткоде?
В общем эту статью нужно дописать будет на досуге. В любом месте страницы, до того момента как был вызван wp_footer() можно писать такую вот конструкцию для подключения яваскрипт:
wp_enqueue_script(«my_script», get_bloginfo( ‘stylesheet_directory’ ).’/js/my_script.js’,array(‘jquery’),»0.1″,true);
P.S. вместо true можно писать false так вроде лучше работает
Не совсем понял последний вариант. Нужно вставлять код прямо на странице? Вроде же это не очень хорошо?
В общем с нетерпением жду обновления статьи с «правильным решением» подключения по требованию скриптов на странице/постах.))
Спасибо
1) Если ваш скрипт используется на всем сайте то правильней всего его подключать через wp_enqueue_script в файл functions.php (понятное дело в этом случаи не нужно ни каких if() условий)
2) Если вам нужно подключить скрипт в шорткоде то в сам шорткод в начало или конец вставляем wp_enqueue_script как я писал выше (тогда тоже условия не нужны).
3) Если нужно вставить на конкретную страницу или в конкретный шаблон, тогда лучше всего вставлять через functions.php но с добавлением правильного условия. например нужен код только на страницах поста, мы пишем if(is_single())
Давайте я поясню на своем примере.
Я хотел бы подключить скрипт кластеризации карт от гугл. Но используется он всего лишь на нескольких страницах их 600 (там где я вывожу карты). Скрипт достаточно тяжелый. Зачем грузить его на все страницы? Шорткодом было бы удобно, но вы говорите это не правильно.
Вот и думаю как сделать так чтобы только на определенных страницах/постах подключался этот скрипт, но, при этом, это было бы правильно реализовано. Через мета поле, как мне кажется, это было бы самым удобным вариантом.
Добрый день. Это конечно хорошо. Скрипт я подключил. Но как блин вызвать функцию из этого скрипта? onClick по кнопке wordpress обрезает. Я уже запарился гуглить.
Как подключить скрипт на сторонний сайт
Привет, Хабр! Это первый пост в нашем блоге. Многие знают нас как чат для сайта, именно с него мы начинали, а сейчас занимаем лидирующие позиции в сфере бизнес-мессенджеров. Мы постепенно эволюционировали в комплексное бизнес-решение, которое предоставляет множество возможностей для клиентов: callback, общение с клиентами через мессенджеры, соцсети, мобильные приложения, виртуальная АТС, CRM-функции и многое другое.
За несколько лет мы успешно решили множество технических проблем, накопили много интересного, а местами и уникального опыта, конечно же, писали свои костыли и велосипеды. Этим постом мы начинаем серию статей, в которых будем делиться своим опытом разработки, выстраивания процессов в полностью удаленной команде, расскажем про нашу архитектуру, технические решения, которые позволяют нам эффективно обслуживать сотни тысяч клиентов по всему миру.
Jivosite сегодня это:
Входная точка
Театр начинается с вешалки, а подключаемый сервис с кода-вставки. Он является входной точкой для любого сервиса или модуля на сайт. Как правило, его можно найти в инструкции установки, после чего необходимо добавить его в HTML-код сайта, а дальше происходит «магия», которая определенным образом загружает и инициализирует скрипт.
Казалось бы, что может быть проще подключения скрипта на сайт? По стандарту, необходимо просто добавить тег script в HTML-код страницы. Но на самом деле это важный этап, скрывающий много подводных камней. Например, идентификация пользователя, реализация резервного канала загрузки скрипта, настройка внешнего вида или логики, скорость загрузки страницы и так далее. Но давайте обо всем по порядку.
Идентификация
Просто так подключать скрипт мало кому интересно, наверняка скрипт выполняет какую-либо логику, а эта логика привязана к пользователю. Например, ID счетчика, APP_ID от соцсети, в нашем случае это ID созданного канала связи. То есть скрипт должен идентифицировать пользователя в запросах на сервер. Для идентификации клиента через код-вставки есть три варианта реализации.
Передавать ID прямо в ссылке на файл и на стороне сервера каким-либо способом прокидывать его в скрипт. В этом случае серверу на лету придется прописывать ID в файл или формировать JS-строку c ID, которая будет загружать file.js. Эта логика похожа на реализацию JSONP-запросов.
Долгое время мы работали по такому принципу, но минусы этого подхода в том, что добавляется «холостая» нагрузка на сервер и необходимость реализации серверного кэширования.
Атрибут async — говорит браузеру о том, что не нужно дожидаться загрузки скрипта для построения DOM, скрипт надо выполнить сразу после загрузки. Это уменьшает время загрузки страницы, но есть и обратная сторона медали: скрипт может выполняться до того, как DOM будет готов к работе.
Одна из самых популярных реализаций, так делают в том числе и крупные сервисы, отличается только синтаксис, но суть у всех одна.
У такого подхода есть два основных минуса, первый — усложняется код-вставки, а второй — очень важен порядок выполнения данного кода, в противном случае ничего работать не будет. К тому же необходимо делать выбор между скоростью (async) и стабильностью (без async), большинство выбирают 2-й вариант.
Аналогично первому варианту передавать ID в ссылке на файл, но извлекать его в браузере, а не на сервере. Это не так просто, как кажется, но возможно. В API браузера есть свойство document.currentScript, оно возвращает ссылку на скрипт, который загружен и в данный момент выполняется в браузере. Зная это, можно вычислить ID, для этого надо получить свойство document.currentScript.src и регуляркой вытащить из него ID.
Есть одно но: document.currentScript поддерживается не всеми браузерами. Для браузеров, не поддерживающих это свойство, мы придумали интересный хак. В коде file.js можно выбросить специальное «фейковое» исключение, обернутое в try/catch, после чего в стеке ошибки будет URL скрипта, в котором произошла ошибка. URL будет содержать ID, который мы получаем той же регуляркой.
Вот такая магия получается, но это работает. Нет заморочек с порядком выполнения, код-вставки выглядит просто и нет оверхеда на сервере. Последние два года мы используем именно такой подход, хотя сам код-вставки у нас отличается, но принцип тот же.
Настройки
В большинстве случаев у подключаемых скриптов есть какие-либо настройки, отвечающие за внешний вид или логику работы. Эти настройки необходимо «прокидывать» в подключаемый скрипт, для этого существуют два принципиально разных подхода.
К этому подходу также относится передача настроек в GET параметрах url скрипта, аналогично варианту #1 из раздела «Идентификация». Подход заключается в том, что если клиент хочет поменять настройки, то ему необходимо отредактировать код-вставки и обновить его на сайте.
Это хорошо тем, что все настройки хранятся на клиенте и их не надо хранить на сервере, разрабатывать и обслуживать всю связанную с этим бизнес-логику. Главным минусом такого подхода является неудобство для клиента, ему приходится все делать вручную, а если настроек много, то код-вставки превращается в сложно поддерживаемую простыню, в которой легко допустить ошибку. А чтобы обновления вступили в силу, надо обновлять сайт, это лишние телодвижения разработчиков и админов.
Второй подход заключается в том, что в случае необходимости изменения настроек клиенту не надо модифицировать код-вставки, все настройки хранятся на сервере. Для того чтобы поменять настройки, надо зайти в графическую панель, изменить нужные параметры и нажать кнопку «Сохранить». После этого настройки автоматически применятся для его сайта!
Не надо разбираться в коде и делать ради этого деплой, этим может заниматься человек, далекий от JavaScript, например менеджер. Конечно для пользователей такой вариант гораздо удобнее и проще, поэтому именно его мы используем. Но за удобство надо платить, такой подход требует разработки и поддержки логики на сервере и подразумевает дополнительную нагрузку на него. В следующих статьях мы обязательно расскажем, как мы ежедневно обрабатываем 150М таких запросов.
Обратная совместимость
Очень важно максимально быстро прийти к зрелой версии кода-вставки. Потому что обновлять уже установленные коды-вставки будет крайне сложно. Пример из нашей практики: в первых версиях мы использовали числовые ID, но по соображениям безопасности заменили их на число-буквенные. Оказалось, что очень сложно добиться изменения уже установленного кода-вставки. Многие даже не знают, что такое HTML и как устроены сайты. Например, сайт делали фрилансеры, студия или сайт создавался через CMS/конструктор и т. д. В большинстве случаев наши клиенты работают только с панелью настроек виджета. С тех времен у нас до сих пор в nginx работает мапа реврайта старых ID на новые, в которой около 40К записей.
Из-за этой особенности мы вынуждены сохранять обратную совместимость кода-вставки при всех рефакторингах, которых на нашей памяти было около 5.
Изоляция кода
Так как скрипт подключается на сторонний сайт, на котором уже есть JavaScript и CSS код сайта и других сервисов, первостепенной целью является не навредить сайту, чтобы наш код не изменил логику, а тем более не сломал ее. Это может быть JavaScript-ошибка, которая останавливает поток выполнения, или стили, которые переопределяют стили сайта. Но и код сайта может саффектить подключаемый скрипт, например используется библиотека которая модифицирует браузерное API, после чего код перестает работать или работает не так, как мы ожидаем.
Есть разные варианты изоляции кода. Например можно использовать префиксы в JS переменных, замыкания, чтобы не засорять глобальный контекст, использовать что-то наподобие БЭМ для стилей. Но самый простой способ — это выполнения кода в iframe, он решает большинство проблем изоляции, но накладывает определенные ограничения. Мы используем гибридный вариант, про изоляцию кода расскажем подробнее в следующих статьях.
Блокировка загрузки сайта
Событие onload — наступает после того, как веб-страница полностью загружена, включая изображения, стили и внешние скрипты. Важная особенность в том, что на большинстве сайтов JS-логика, сторонние скрипты и реклама начинают работать по наступлению этого события. Очень важным пунктом для всех подключаемых скриптов является не допустить негативного влияния на это событие.
Это происходит в тех случаях, когда сервер, с которого грузится скрипт, отвечает долго или вовсе не отвечает: тогда событие onload откладывается и дальнейшая загрузка страницы по сути блокируется. В случае, когда сервер недоступен, событие onload наступит только по истечении таймаута запроса, который больше 60 с. Таким образом, проблемы на сервере отдачи скрипта по сути «ломают» сайты, что является недопустимым.
Личный опыт
В прошлом я работал в компании, у которой был сайт с одновременным онлайном 100К, онлайн-знакомства. В те времена были попопулярны кнопки «Поделится в соцсетях». Чтобы они появились на сайте, надо было подключить скрипт (sdk) от нужных соцсетей. В один прекрасный день к нам прибежали коллеги и сказали, что наш сайт не работает! Мы посмотрели в мониторинги, в которых все было нормально, и сначала не поняли, в чем проблема. Когда начали разбираться глубже, поняли, что cdn-сервера Twitter прилегли, и их SDK не мог загрузиться, это блокировало нам загрузку сайта на
1.5 минуты. То есть после открытия сайта загружался небольшой HTML(остальное SPA) и только через 1.5 минуты все прогружалось, срабатывал тот самый таймаут запроса. Нам пришлось экстренно организовывать хотфикс и убирать их скрипт с сайта. После повтора этой ситуации мы решили убрать блок «Поделиться» совсем.
В первых версиях кода-вставки у нас не было это учтено, и в случае технических проблем на нашей стороне мы, мягко говоря, доставляли неудобства нашим клиентам, но со временем мы это исправили.
Решение простое, надо подписаться на событие полной загрузки сайта и только потом загружать скрипт, для этого надо использовать код-вставки, а не тег script.
Google Pagespeed
Результаты анализа мобильной версии habr.com
Большинство уделяют внимание скорости загрузки сайта, по многим исследованиям это напрямую влияет на прибыль, к тому же поисковые алгоритмы при ранжирование стали учитывать время загрузки страницы. В связи с этим владельцы сайтов часто используют подобные инструменты для оценки производительности сайта. Поэтому очень важно оптимально подключать код на сайт, так он напрямую влияет на его время загрузки.
Это означает, что надо использовать современные техники оптимизации загрузки страниц. Например использовать Gzip, кешировать статические файлы и запросы, использовать асинхронную загрузки скриптов, сжатие статики современными алгоритмами такими как WebP/Brotli/etc и использовать другие оптимизации. Мы регулярно проводим аудит и реагируем на предупреждения и рекомендации, чтобы соответствовать современным требованиям.
В первых версиях мы загружали статику с серверов приложения. Но у такого подхода есть минусы: дорогой трафик, удаленность от посетителей сайтов и излишняя нагрузка на канал серверов. Можно легко забить канал серверов приложения при хабр-эффекте сайтов, так как трафик статики очень «тяжелый».
С целью экономии бюджета, стабильности и уменьшения сетевой задержки оптимально загружать статику со специально предназначенных для этого серверов. Можно использовать готовые CDN-провайдеры, но на больших масштабах это недешево и приходится ограничиваться возможностями, которое предоставляет тот или иной провайдер.
Мы реализовали это просто, заказали недорогие сервера в России, Европе и Америке с безлимитным трафиком и широким каналом. Это дешево, не накладывает на нас никаких ограничений, мы можем настроить все под себя, а отказоустойчивость обеспечивается за счет механизма, работающего в браузере. В данный момент с наших CDN-серверов загружается 1ТБ статики ежедневно.
Отказоустойчивость
К сожалению, мир не идеален, случаются пожары, аплинки падают, ДЦ целиком уходят под воду, РКН блочит подсети, а люди совершают ошибки. Тем не менее, необходимо уметь обрабатывать такие ситуации и продолжать работать.
Мониторинг
Сначала надо понять, что что-то пошло не так. Можно, конечно, подождать, пока пользователи придут и пожалуются, но лучше настроить мониторинг и алерты, а после релизов, проверять все ли в порядке. Мы мониторим много различных параметров, как серверных, так и клиентских, и если что-то пошло не так, мы сразу это видим. Например, уменьшилось количество загрузок виджета или аномальный всплеск трафика на CDN-серверах.
Суммарное кол-во загрузок виджета по каждой версии
Сбор ошибок
JavaScript очень специфичный язык, и допустить в нем ошибку несложно. К тому же зоопарк браузеров в современном вебе очень большой; то, что работает в последнем Chrome, не факт, что будет работать в Safari или Firefox. Поэтому очень важно настроить сбор ошибок из браузера и вовремя реагировать на всплески. Если ваш код работает в iframe, то сделать это можно отслеживая глобальный обработчик window.onerror и в случае ошибки отправлять данные на сервер. Если код работает вне iframe, то реализовать сбор ошибок очень сложно.
Суммарное кол-ва ошибок со всех сайтов и браузеров
Информация по конкретной ошибке
CDN Failover
Выше я уже писал, что все имеет свойство падать, поэтому важно обрабатывать эти ситуации и лучше — автоматически. Мы прошли несколько этапов фаллбека CDN-серверов, начинали с ручного, а в итоге нашли способ делать это автоматически и оптимально для браузера.
В ручном режиме это работало просто: админам приходило СМС о том что CDN прилег, они совершали определенные манипуляции, после чего виджет начинал загружаться с серверов приложения. Это могло занять от 5 минут до 2 часов времени.
Для реализации автоматического фаллбека необходимо как-то детектить, что загрузка скрипта началась, но сделать это не так просто, как кажется. Браузер не дает возможности отслеживать промежуточные состояния загрузки тега script, как например событие onprogress в XMLHttpRequest, а сообщает только событие по окончанию загрузки и выполнения скрипта. Также нельзя за приемлемое время узнать, что сервер в данный момент недоступен, единственное событие onerror срабатывает по истечении таймаута запроса, больше 1 минуты. За минуту посетитель может уже покинуть страницу, а скрипт так и не загрузится.
Мы пробовали разные варианты, простые и сложные, но в итоге пришли к решению с ping-запросом CDN-сервера. Работает это так: мы сначала пингуем CDN-сервер, если ответил, то тогда мы загружаем виджет с него. Чтобы реализовать эту схему оптимально для браузера и наших серверов, мы используем легкий HEAD-запрос (без тела), а при последующих загрузках мы его не делаем, пока не обновится версия виджета, т. к. виджет уже в кеше браузера.
Таким образом мы получили очень быстрый и автоматически детект доступности сервера статики и в случае падения практически без задержек переходим на резервный сервер.
Loader
Чтобы загрузить свой скрипт на сторонний сайт, надо учесть множество моментов, но реализовать эту логику в коде-вставки сложно, так как он просто превратится в «мясо». Но делать это все равно надо, для этого мы создали небольшой модуль, который управляет всей этой логикой «под капотом» и загружает основной код виджета. Он загружается в первую очередь и реализует CDN Failover, кеширование, обратную совместимость со старыми кодами-вставки, А/Б тестирование, постепенную выкладку новой версии виджета и множество других функций.
Таким образом поэтапно мы пришли к схеме, которая покрывает основные кейсы загрузки и инициализации виджета. Она доказала свою эффективность за годы использования на большом количестве различных сайтов. При этом код-вставки остается простым и универсальным, так как в нем нет никакой логики и мы в любой момент можем ее поменять, при этом не заставляя пользователей менять код-вставки.
Сторонние сервисы
Ну и напоследок стоит упомянуть про сторонние сервисы, которые подключаются на сайт или каким-либо образом взаимодействуют с сайтами: поисковые боты, аналитика, различные парсеры и так далее. Эти сервисы оставляют отпечаток на работе, про это тоже не стоить забывать. Расскажу несколько случаев из нашей практики.
GoogleBot
В нашем приложении оператора есть функция «Посетители», в которой можно посмотреть посетителей, в данный момент просматривающих сайт, и различную информацию по ним: время на сайте, страницу, число просмотренных страниц и так далее. В определенный момент клиенты начали жаловаться, что у них «висят» посетители с других сайтов, то есть на сайте по продаже айфонов, клиент, у которого якобы открыта страница «Купить крем для лица». Когда начали разбираться, выяснили, что это GoogleBot, который при переходе от сайта к сайту кешировал LocalStorage первого и впоследствии передавал неправильные данные на сервер.
Решение простое, на сервере начали игнорировать данные от GoogleBot.
Яндекс.Метрика
В метрике есть замечательная функция — вебвизор, которая позволяет посмотреть, что видел и делал пользователь, в виде скринкаста. Для этого метрика записывает все действия пользователя, а после специальный бот метрики ходит по сайтам, совершает те же действия и записывает это. Проблема была в том, что для эмуляции мобильного браузера пользователя, по нашим данным, включался Firefox в режиме мобильной эмуляции, но при этом userAgent у бота был десктопный.
Это приводило к тому, что при просмотре мобильных пользовательских сессий в вебвизоре на записи открывалась десктопная версия виджета, хотя на самом деле у пользователей открывалась мобильная. Наши клиенты думали, что так и есть, и заваливали нас жалобами. В итоге нам пришлось детектить, что виджет загружен в вебвизоре, понимать, что в нем открыта мобильная версия, и в этом случае подсовывать туда мобильный виджет.
Примеров намного больше, но, думаю, этого будет достаточно для понимания сути.
Заключение
Надо очень внимательно относиться к коду, который вы отдаете клиентам для вставки на сайт. Мы кратко рассказали, с какими проблемами мы столкнулись и как их решали. В следующих статьях мы более подробно расскажем про некоторые упомянутые темы и другие участки нашей системы, например, как мы используем NodeJS в качестве бэкенда, как держим нагрузку всех 270К сайтов за счет продуманного кеширования и не боимся хабра-эффекта подключенных к нам сайтов, как работаем в полностью распределенной команде и многое другое.
Спасибо за внимание, будем рады ответить на ваши вопросы и комментарии!