уменьшите влияние стороннего кода битрикс
Yandex Metrika: Сторонний код заблокировал основной поток
Для веб-мастеров не секрет, что Google’s PageSpeed Insights снимает баллы за код счётчика Яндекс.Метрики. Почему? Банально из за того, что файл tag.js грузится со стороннего ресурса достаточно медленно. У меня показывает 600+ микросекунд.
Убрав счетчик Yandex Metrika, я получаю примерно на 4 балла больше. Это, на минутку, ускорение загрузки на 4%! Но Яндекс.Метрика необходима, как удобный инструмент веб-аналитики, а потому выпиливать её не вариант.
Что остаётся?
Способ №1
Остаётся скачать файл tag.js к себе на сервер, скажем, в папку metrika и использовать его оттуда.
Вот так выгладили баллы в Google’s PageSpeed Insights до этой правки.
Очевидно, эффект есть. Но есть и минус. Файл tag.js может меняться, а значит время от времени его нужно скачивать. Руками… Фи!…
Руками качать не будем. Пусть этим занимается Крон. Не тот, который титан из греческой миффологии, а который CronTab на хостинге. Скажем, раз в час.
А теперь пошаговая инструкция на примере хостинга Бегет.
Итак, если Google’s PageSpeed Insights ругается, что сторонний код заблокировал основной поток и винит в этом счетчик Yandex Metrika, мы делаем следующее:
Шаг 1: Создаём в корне сайта папку metrika.
Для этого заходим в корень сайта с помощью FTP-клиента и… Если вы не знаете что такое корень сайта или FTP-клиент, то у вас есть три выхода:
К слову, вместо FTP, можно использовать SSH-клиент или даже Файловый менеджер, который есть в панели управления хостингом (у Бегета он точно есть).
Шаг 2: Скачиваем tag.js и копируем его в папку metrika, созданную в предыдущем шаге.
Тут тоже всё просто. Ссылка на файл есть в коде счётчика Яндекс Метрики. Вот она https://mc.yandex.ru/metrika/tag.js
Просто переходим по ней, а когда файл откроется в браузере, сохраним его комбинацией клавиш Ctrl-S, а затем просто скопируем в папку.
Шаг 3: Вносим правку в код счётчика Яндекс Метрики.
Находим ссылку на tag.js и делаем так, чтобы она ссылалась на папку в корне вашего сайта.
Было (window, document, «script», «https://mc.yandex.ru/metrika/tag.js», «ym»);
Стало (window, document, «script», «/metrika/tag.js», «ym»);
Сохраняем и идём дальше.
Шаг 4: Узнаём полный путь к корню сайта на сервере.
В вебе корень сайта начинается с /. В файловой системе сервера путь до корня может выглядеть примерно так /r/username/sitename/public_html/.
Т.е. корень сайта там лежит в папке, а та в папке, и она, в свою очередь тоже в какой-нибудь папке. Но нам надо знать полный путь, чтобы указать его в кроне.
Убираю index.php, остаётся /home/w/redalert/sitename.ru/public_html/. Это и есть нужный мне путь.
Теперь, когда путь известен, не забываем убрать из подвала сайта!
Шаг 5. Настраиваю задание для крона.
Не знаю как у вас, а на Бегете достаточно зайти в панель управления хостингом и нажать кнопку CronTab.
На открывшейся странице я выбираю произвольную команду, делаю для неё понятное описание, и выбираю её выполнение каждый час.
Сама команда выглядит вот так. Если у вас другой хостинг (не бегет) то найдите способ внедрить её в задачу для крона тем способом, который поддерживается хостингом.
/home/w/redalert/sitename.ru/public_html/ — это тот путь к корню сайта, который я получил в шаге 4.
/metrika/ — это папка где мы будем хранить tag.js и откуда он будет грузиться на сайте.
Теперь раз в час крон будет обновлять tag.js без нашего участия.
Собственно, сохраняю и иду измерять скорость в Google’s PageSpeed Insights.
Ура! Она на 4% выше, как и ожидалось.
Способ №2
Ну а теперь, для самых стойких, способ номер 2. Подойдёт тем кому лень заморачиваться с кроном.
1. Заходим на сервер в корневую папку сайта.
2. Создаём там папку metrika.
3. Кладём в папку metrika файл tag.php
4. В коде счётчика меняем https://mc.yandex.ru/metrika/tag.js на /metrika/tag.php
5. В файл tag.php прописываем вот этот код.
или скачиваем архив с готовым файлом по ссылке /up/metrika.zip и распаковываем в корень сайта (там уже есть нужная папка и даже tag.js в ней имеется).
6. Тестируем результат.
Как это работает?
При обращении к tag.php, если tag.js отсутствует в папке metrika или с момента его последнего обновления прошло больше часа, tag.js будет скачан с серверов яндекса и его содержимое подставится в tag.php.
Если tag.js свежий, то его содержимое будет подставлено в tag.php сразу.
Просто, очень просто, примитивно даже. Создали папку, кинули туда файл, заменили строчку в счётчике и всё.
А теперь полевые испытания. Есть у меня сайт wowm.ru. Он не оптимизирован, а значит идеально подходит для эксперимента.
Замеряю скорость до изменений.
Ставлю новый код счётчика (оказывается там был старый), меняю в нём путь к tag.js на свой. Ну и далее по инструкции.
И вот вам результат.
Миленько так. Т.е. стало медленнее.
Может дело в старом коде счётчика?
Ок. Тестируем скорость на новом счётчике, где tag.js берется с серверов яндекса. А затем тестируем скорость с tag.php
Вывод
1. Сообщение «Сторонний код заблокировал основной поток» исчезло.
2. Прироста в скорости, при использовании способа №2, не наблюдается, а даже наоборот.
3. Старый счётчик яндекс.метрики был быстрее.
А с вами был Доктор Лексиум.
Спасибо за внимание.
После проделанных манипуляций общая оценка Page Speed Insight одной страницы
Было 84
Стало 58
Нет, некоторые показатели улучшились, уменьшение влияния стороннего кода удалось,
но в общем целом незачет получился — вернул как было
У каждого сервера и сайта своя структура. Кому-то этот вариант помогает, как мне например. Кому-то нет.
Я использовал этот способ на нескольких сайтах и там был прирост скорости. Небольшой, конечно, но всё-же.
Все так запутано, нет ли какого-нибудь способа попроще?
Как не быть? Есть. Я добавлю его к этому посту.
а где в коде счетчика найти эту конструкцию?
4. В коде счётчика меняем https://mc.yandex.ru/metrika/tag.js на /metrika/tag.php
В коде счётчика)) Она либо там есть, либо нет. Если нет, значит у вас старый счётчик.
День добрый.
За инфу спасибо.
Но есть вопрос.
Почему плагин? Он позволяет настройками исключить посещение сайта пользователями-админами.
Ваш способ это не позволяет. Или есть возможность организовать аналогичный функционал?
Насколько мне известно, в настройках самой метрики можно указать IP адреса которые следует игнорировать. Обычно SEO-специалисты именно так и делают.
Что касается плагина. Я не лазил в его код, но уверен, что он всего-лишь определяет админ ли пользователь. Если админ, код счётчика на страницах сайта не выводится вовсе. Без плагина это можно сделать двумя строчками кода. При том, вторая строка это фигурная скобка.
Однако, такой способ хуже поскольку до авторизации администратора, код метрики будет присутствовать на страницах, а значит все шатания неавторизованного админина зафиксируются счётчиком метрики.
Когда же Гугл перестанет учитывать метрику при оценке скорости загрузки? Свои коды наверняка не считает.
Пока такая ситуация сохраняется, Гуглу нет никакого смысла не учитывать скрипты Яндекса.
Спасибо за статью. Очень полезная информация.
На здоровье. Надеюсь пригодится.
Тут как раз очень редкий случай, когда лучше поставить плагин. Мой сайт https://tv-ch.ru/ показывал в PageSpeed Insights
99 балов, с установкой кода «Яндекс метрика» упал на 10. Но, спасибо автору, установил плагин «Яндекс.Метрика by Alexander Semikashev». Сейчас там можно и поставить устаревший код яндекс, который очень сильно понижает скорость сайта, и просто вставить код счетчика. Что на много проще и не снижает скорость сайта!
Еще раз спасибо автору, за то что указал на данный плагин. Раньше его не ставил по причинам «мало балов и установок». Но плагин оказался отличным!
Рассмотрим причины, почему сайт вообще может работать медленно. Их на самом не так и много, и в общем случае они делятся на 2 класса:
Долгая работа на стороне сервера
Долгая загрузка и работа на стороне клиента(браузера)
На скорость работы на стороне сервера влияют:
Основными проблемами на стороне клиента являются
Рассмотрим каждую проблему более подробно.
CMS 1C-Bitrix достаточно требовательна к ресурсам, точнее к их оптимальной настройке. На сайте Битрикс вы можете найти рекомендуемых хостинг-партнеров.
Данная компания находится в лидерах рейтинга Битрикс среди хостеров, у них производительные конфигурации и довольно быстрая поддержка. К тому же при заказе сервера или VPS они сами их администрируют. Проверить производительность системы можно на административной странице по адресу:
Производительность менее 30 уже является основанием для замены или оптимизации хостинга. Кое-что можно сделать и самому в админке сайта. Перейдите на страницу модулей и отключите неиспользуемые модули.
Перед этой процедурой на всякий случай сделайте бекап, т.к. при удалении модуля могут быть удалены и его таблицы. Мы обычно рекомендуем отключить модуль веб-аналитики, т.к. его работу выполняют Яндекс.Метрика или Гугл.Аналитика. Так же можно отключить модуль компрессии, т.к. его работу выполняет GZIP. Остальное зависит от потребностей вашего проекта.
Следует учитывать, что производительность зависит от текущей нагрузки на сайт. Если в текущий момент происходит полный обмен с 1С, производительность будет ниже (возможно в разы), чем в обычном рабочем состоянии.
Ошибки в настройке системы
На панели производительности следует обратить внимание на Конфигурацию, она должна быть отмечена как «Оптимально». Версия РНР рекомендуется не ниже 7.0, т.к. она практически вдвое быстрее 5.Х версий. Непосредственно к скорости работы это отношения не имеет, но сайт должен проходить проверку по адресу:
Так же стоит обратить внимание на настройки сервера базы данных.
В идеале не должно быть «красных» значений, все рекомендации должны быть выполнены. Под сервер БД рекомендуется отводить порядка 70-80 % оперативной памяти сервера. Заметим, что данные настройки не стоит изменять самостоятельно, если вы не знаете на 100%, как это делать. Можно вызвать ошибку MySQL сервера и ваш сайт вообще перестанет работать.
Настройка кеширования в Битрикс
Случается, что допустив ошибку в разработке, пытаются скрыть ее за счет отключения кеширования. Для заказчика при демонстрации все работает, но при реальной нагрузке сайт начинает сильно тормозить. Либо кеширование могут отключать при разработке, а после забывают включить обратно.
Чтобы проверить, настроено ли у вас кеширование, нужно пройти на страницу
Вы должны видеть, что кеширование у вас включено и работает. Если оно отключено, включаем и обязательно проверяем работу сайта, причем страницу надо открыть 2 раза. Наиболее частые ошибки при рабочем кеше – некорректная работа мета тегов title и description. На глаз можно и не заметить разницы, поэтому следует просматривать и код страницы.
Далее, кеширование нужно проверить в публичной части сайта с помощью административной панели.
Для этого нажимаем на кнопку «Отладка» и смотрим в левом нижнем углу информацию о скорости построения страницы.
При повторной загрузке страницы вы должны видеть меньшие цифры создания страницы, чем при первой загрузке или загрузке со сброшенным кешем. Это означает, что кеширование работает.
В нашем случае мы видим первую загрузку за 0.95 секунд, вторую за 0.28.
Это нормальные результаты. Если вы не видите существенного изменения скорости, то стоит детально изучить причины происходящего. Возможно у вас отключено кеширование на уровне компонентов, или внутри самих компонентов происходит сброс кеша.
Частый сброс кеша – еще одна распространенная проблема. Если у вас работает контент менеджер, то он будет сбрасывать кеш со всего каталога каждый раз, когда сохраняет один из его элементов. А если этих элементов у вас десятки тысяч? Во-первых, сама процедура сброса будет отнимать ресурсы у сайта. Во-вторых, толку от вашего кеширования будет немного, так как каждые 3-5 минут он будет сбрасываться. Для исправления ситуации есть 2 пути:
вынести изменение контента за пределы сайта, например, на сторону 1С или Моего Склада и выгружать изменения раз в сутки
выключить управляемый кеш и настроить оптимальное время кеширования компонентов
Выключить управляемый кеш можно по адресу:
Ошибки разработки, которые тормозят сайт на Битрикс
В сайтах на 1С-Битрикс есть собственный механизм поиска ошибок разработки, и поиск проблем следует начинать именно с него.
В уже упомянутом механизме Настройки – Производительность – Панель производительности есть вкладка Разработка, куда помещаются страницы, создающие самую большую нагрузку. Данный инструмент хорош тем, что позволяет видеть все хиты, а не только те, что видны в публичной части. Например, был случай, когда основную нагрузку создавал ajax запрос, который никак не проявлял себя при обходе сайта. На скриншоте ниже видно, что основную нагрузку создает страница каталог.
Для выявления ошибок разработки нам поможет все тот же механизм «Отладка». С помощью него можно вычислить, какой из компонентов выполняется слишком много времени.
Для примера рассмотрим такую картину: карточка товара, отрабатывает за 6 секунд.
Детальный анализ показывает, что меню строиться 1,5 секунды, и еще 4,5 секунды занимает компонент element.detail.
Теперь мы знаем куда копать, и находим с помощью отладки куски кода, которые занимают максимальное время. Для отладки можно использовать как РНР функцию microtime(), так и более совершенные инструменты – xdebug или XHProf. Тут важно отметить, что не рекомендуется использовать xdebug на боевых сайтах, т.к. он довольно сильно замедляет работу. И если уж вы использовали его на боевом проекте, проследите за тем, чтобы после отладки модуль был отключен. На выходе вы должны получить список мест, где ваш проект тормозит больше всего. Далее, оптимизируем код, сохраняя бизнес логику. Бывают случаи, когда и вовсе приходится менять логику работы, либо выносить тяжелые вычисления на агентов или крон.
Ошибки в архитектуре и настройках веб сайта
Пожалуй, это наиболее существенная проблема из всех описанных. Бывает, что проще с нуля проект разработать, чем пытаться исправить ошибки проектирования. Приведем пример: на одном сайте для вывода раздела каталога выполнялась выборка всех элементов и всех разделов. Работала она 6-8 секунд, и если сбрасывался кеш, то сайт просто «умирал». А для исправления ситуации надо было разделить данные на несколько инфоблоков, и перестроить работу на стандартные компоненты. Вообще, если у вас много разделов и в этих разделах много уникальных свойств, постарайтесь разделить их на отдельные инфоблоки. Это конечно создаст новые проблемы с совместным выводом элементов, но это по крайней мере решаемо 🙂
Другой момент, замедляющий работу – это обращение к внешним сервисам. Чаще всего это сбор курсов валют, информер погоды или служба доставки. Если вы получаете эти данные в коде страницы, то гарантированно затормозите этим сайт. Подобный функционал следует подключать либо на кроне, либо переводить на аякс запрос, а пока он выполняется показывать пользователю заглушку или прелоадер.
Следует проверить, чтобы работа агентов выполнялась на кроне, а не на хитах. В противном случае посетители будут ждать пока отправятся письма и построится фид в Яндекс.Маркет. Перевести агенты на крон поможет урок из курса для разработчиков
Либо модуль, который работает только на виртуальных машинах BitrixVM
Проверить работу агентов можно на странице «Проверка системы».
В настройках главного модуля следует включить быструю отдачу файлов через Nginx.
Не оптимизированная графика
Наиболее частый сценарий – это использование размеров изображений, которые не соответствуют отображению в браузере. Например, у нас на странице выводится список товаров с картинками. Сам контейнер в браузере имеет размер 152 * 190 пикселей, а вот картинка при этом используется 400 * 500 пикселей.
Чтобы исправить эту ситуацию, следует подогнать картинку под размер отображаемой области. Для сайтов на Битрикс для этого используется функция ResizeImageGet. Тут следует быть аккуратным, и учитывать то как выглядит данный блок в адаптивной версии сайта, чтобы не урезать картинку слишком сильно.
Вторым моментом, влияющим на скорость загрузки, является непосредственный «вес» картинки. Чтобы его уменьшить, целесообразно использовать дополнительные модули сжатия на сервере, такие как jpegoptim и optipng.
Для автоматического сжатия есть отличный модуль, который мы используем в своих проектах
Для подготовки изображений, используемых в верстке сайта, рекомендуется использовать сервис:
Суть метода заключается в постепенной загрузке изображений, по мере того, как пользователь до них доходит. Уточним, что если вы используете AJAX подгрузку товаров в каталог (кнопка «Показать еще»), то после каждой загрузки нужно повторно инициализировать данный плагин.
И напоследок о картинках. Лучше использовать для графики формат jpeg нежели png. Разницы в отображении не заметно, зато можно сэкономить на размере изображения.
Сжатие ресурсов сайта
Тут следует остановиться на 2х моментах:
Сжатие средствами Битрикс,
Сжатие на стороне сервера.
Битрикс своими силами может сжимать и склеивать файлы скриптов и стилей. Включается это в настройках главного модуля по адресу:
Мы сразу попадаем в настройки главного модуля, где нас интересуют следующие чек боксы.
Объединять файлы CSS и JS надо в любом случае, это серьезно ускоряет загрузку файлов, т.к. позволяет вместо 20 подключений задействовать всего 1 или 2. Стоит отметить, что будут объединены файлы, которые подключены средствами Битрикс через методы SetAdditionalCSS и AddHeadScript, или их D7 аналоги. Файлы, подключенные напрямую через теги link или script в объединении не участвуют.
С переносом JS в конец страницы нужно быть аккуратным, особенно если проект достался вам на поддержку в наследство. Может случится ситуация, когда у вас инлайном прописана функция, которая использует подключаемые файлы. Это может быть обращение к методу JQuery. После переноса файлов в конец страницы следует внимательно пройтись по всему проекту и проверить его на предмет ошибок javascript в консоли.
На стороне сервера должна быть настроена работа модуля GZIP. Данная служба необходима для сжатия передаваемых данных. В виртуальной машине Битрикс модуль включен по умолчанию, в популярных панелях хостинга настраивается на странице редактирования домена. Если не найдете, напишите в поддержку хостинга, думаю не откажут.
Есть много сервисов проверки на то, включено ли у вас GZIP сжатие. В тесте мы воспользовались вот этим:
Видно, что данный метод позволяет экономить порядка 75% трафика, что особенно актуально для мобильных устройств.
Избыточные стили и скрипты
Достаточно распространенная проблема, если проект поддерживался стихийно, пережил несколько этапов редизайна и накопил в себе гору неиспользуемых стилей и скриптов.
Какого-либо механизма для автоматического обнаружение неиспользуемых скриптов мы не нашли, все проверяется вручную. Тут все зависит от контекста и вы можете использовать console.log() либо точки остановки для того, чтобы понять, попали вы в скрипт или нет.
Чтобы вычислить, какие стили не используются на вашем проекте, поможет инструмент в браузере FireFox под названием csscoverage. Как с ним работать читайте в статье Как удалить лишние CSS стили на сайте.
Следует разделять стили по разным файлам, это так же ускорит отрисовку вашей страницы. Например, на странице каталога ни к чему стили, используемые при оформлении заказа.
Сторонние плагины и скрипты
Тут правило простое: все что вы навешиваете на ваш сайт замедляет его работу. Будь то Яндекс.Метрика, Гугл Tagmanager, Онлайн чат или скрипт сбора статистики, вроде RetailRocket. Встречаются проекты, где этого добра навешано столько, что до момента начала нормального взаимодействия с пользователем проходит 10-20 секунд. Вычислить подобные подключения нам поможет вкладка Сеть(Network) в панели разработчика.
Опрашиваем маркетологов/директоров/менеджеров на предмет необходимости того или иного функционала и аккуратно отключаем. В этом случае лучше закомментировать на время подключение, т.к. кто-то может опомниться спустя неделю или месяц.
Еще один момент заключается в том, что большинство подобных плагинов лучше подключать через отложенную функцию, например спустя 3-5 секунд после загрузки документа. Исключение составляют различные метрики, которым важно быть загруженными как можно раньше.
Слишком большое дерево тегов
Общее правило веб-разработки гласит: можешь обойтись без лишнего элемента – обходись. Приведем пример: тут можно было не оборачивать строку в дополнительный span.
Конечно, единичный случай погоды не делает. Но бывает так, что подобным мусором забито до 20% проекта, что в конечном счете сказывается на производительности.
Распространенной ошибкой являются также лишние элементы, используемые в мобильных версиях. Например, одно меню используется для десктопной версии сайта, другое – для мобильной. Это печальная практика, следует создавать одно адаптивное меню под обе версии.
Сторонний код
Чтобы «разогнать» сайт, проведения одного аудита, а ещё хуже — простого замера скорости,совсем не достаточно. Будучи инструментом со сложной конструкцией, он требует всесторонней работы и изучения возможных ошибок. Наша команда проводит многоступенчатое тестирование и только на основании собранных из нескольких источников данных делает выводы. Затем, исправляется каждый недочёт. Стоит учитывать, что одна ошибка может повлечь за собой целый ряд. Это как в автомобиле, когда неисправность одного узла, тянет за собой поломки в других, а ремонт наиболее очевидной ничего не даёт. Так и при оптимизации сайта — далеко не факт, что проблема кроется в наиболее явной ошибке. Поэтому, корректировки нужно проводить взвешенно и аккуратно. В результате нашей работы — заказчик получает сайт оптимизированный на максимум и с правильными настройками для дальшейшей работы. Это уже не просто страничка в интернете, а полноценный инструмент маркетинга.
Но что делать, если вы уже провели все оптимизации самостоятельно, а сайт всё-равно загружается медленно. Проводя тестирование при помощи сервиса Google PageSpeed Insights, в результатах аудита может отобразиться строка «Сторонний код». Разбираемся, что это значит и как сделать так, чтобы сторонние коды не мешали загрузке страницы.
Что такое сторонние коды и чем они могут навредить
Сторонние коды это всё, что не имеет прямого отношения непосредственно к вашему сайту: реклама, аналитика, трекеры, кнопки социальных сетей, переход на Youtube и так далее. Эти сторонние сценарии могут иметь решающее значение для функциональности сайта или потока доходов. К примеру — рекламные ссылки и банеры. Но сторонние сценарии также сопряжены с целым рядом рисков, на которые нельзя не обращать внимание. А значит, необходимо свести эти риски к минимуму, при этом не потеряв пользы от них.
Чем могут навредить сторонние коды и почему стоит быть с ними внимательным:
● Снижают производительность сайта
● Снижают уровень конфиденциальности пользователей
● Могут нести в себе вредоносные файлы
● Могут быть непредсказуемыми и меняться без вашего на то согласия
● Последствия их использования могут быть непредвиденными
Применяя сторонние коды необходимо полностью удостовериться, что они не влияют на критический путь рендеринга.
Сторонние коды в JavaScript
Мы уже выяснили, что к сторонним кодам относятся любые скрипты, которые встраиваются в сайт от стороннего поставщика. Размещая у себя ссылки на Facebook, VK, Instagram вы тем самым ставите сторонние сценарии, не говоря уже о рекламе и другом контенте. Тем не менее, они увеличивают конверсию и являются полезными.
Одним из наиболее частых является использование видео с Youtube. Вполне логично, что нагружать свою страницу видео файлами не разумно, гораздо логичнее встроить ссылку на видео на абсолютно законном основании. И поскольку это происходит сплошь и рядом, именно на этом примере мы и рассмотрим использование сторонних кодов.
В скриптовом отображении это будет выглядеть таким образом:
Встраивая подобный код мы вполне обоснованно рассчитываем, что отсутствие тяжёлых файлов ускорит процесс загрузки сайта. Но, сторонние сценарии являются основной причиной снижения производительности и часто вызываются не подконтрольными вами ресурсами.
Среди проблем, которые могут всплыть:
● Они могут отправлять слишком много сетевых запросов к нескольким серверам. Чем больше запросов должен сделать сайт, тем дольше он будет загружаться.
● Могут отправлять слишком большое количества JavaScript, который занимает основной поток. Стоит учитывать, что в JavaScript останавливает процесс построения DOM, задерживая скорость отображения страниц.
● Файлы, изображения, видео могут быть не оптимизированы. Это не только негативно влияет на скорость загрузки, но и съедает трафик пользователей.
● Сторонние скрипты, загруженные без осторожности, могут быть единственной точкой отказа.
● Устаревшие API, которые они могут использовать, наносит вред пользовательскому интерфейсу.
Для начала необходимо выявить какие сторонние коды есть на сайте и сколько ресурсов требуется для их загрузки. Как известно — найти проблему, равно половине её устранения. Делается это при помощи специальных инструментов, которые позволяют выявить скрипты, провести их бейнджинг и аудит времени загрузки маяка. Только одним инструментом здесь обойтись невозможно. Необходимо применять все и в определённой последовательности.
Как эффективно загрузить сторонний скрипт?
Без сторонних кодов на сайте зачастую обойтись сложно и тому есть несколько вполне разумных объяснений. Соответственно, необходимо данные скрипты использовать эффективно. Для того, чтобы повысить производительность существует несколько вариантов:
● Загрузите код, используя атрибуты «async» или «defe»r, во избежание блокировки анализа документа.
● Рассмотрите возможность самостоятельного размещения кода, если сторонний сервер работает медленно.
● Удалите скрипт, если он не приносит пользы сайту, а только впустую потребляет ресурсы
Все сторонние коды и сценарии необходимо запускать асинхронно, чтобы они не блокировали DOM, и анализ HTML-документа продолжался. При этом, не подавайтесь на уловки поставщика сторонних кодов, которые предполагают синхронную загрузку. Это негативно скажется не на их, а на вашем сайте. Корректные настройки произвести можно всегда. Для этого потребуются грамотные специалисты, которые разберут коды на составляющие и встроят их так, как нужно.