Удалите код javascript препятствующий отображению wordpress: видео уроки, инструкции для начинающих

Как устранить ресурсы, блокирующие рендеринг в WordPress

Если вы слышите жалобы на скорость загрузки вашего веб-сайта или хотите ускорить загрузку веб-страниц и улучшить взаимодействие с пользователем, вы можете подумать о том, как устранить ресурсы, блокирующие рендеринг.

Независимо от причины, то, как быстро веб-сайт появляется перед лицом посетителя, может повлиять на взаимодействие с пользователем и привести к тому, что ваш бизнес упустит связи с клиентами. Опыт пользователя на веб-сайте в основном зависит от критического пути рендеринга и управления сценариями, которые ваш веб-сайт загружает в процессе рендеринга.

Содержание

Что такое рендеринг?

Все веб-сайты следуют пути, по которому пользователь может видеть и взаимодействовать с их содержимым. Путь загрузки веб-сайта называется критическим путем рендеринга. Этот путь описывает шаги каждого сайта по сбору и созданию данных для посетителя и его браузера.

Что браузеры делают перед рендерингом

Настольный браузер FireFox

Ввод URL-адреса веб-сайта запускает следующий процесс:

1. Навигация завершается, когда пользователь запрашивает определенный URL-адрес.
   1. Происходит поиск DNS, при котором сервер предоставляет IP-адрес
   2. Браузер и сервер веб-сайта выполняют рукопожатие TCP для установления соединения.
   3. Запросы на безопасное соединение получают согласование TLS или второй обмен рукопожатием
2. Браузер получает ответ и получает код веб-сайта.
   1. Первый пакет данных получен в TCP Slow Start для регулирования сетевого трафика.
   2. Пользователь отправляет подтверждения (ACK) на сервер, чтобы установить ограничения соединения и скорость отправки.
3. Браузер анализирует информацию и преобразует данные в объектную модель CSS (CSSOM) и объектную модель документа (DOM).
   1. Строится DOM-дерево (структура сайта и страницы)
   2. Сканер предварительной загрузки собирает внешние ресурсы, такие как сценарии и изображения.
   3. Создается CSSOM (дерево стилей)
   4. JavaScript компилируется во время сборки CSSOM
   5. Объектная модель специальных возможностей (AOM) создана для вспомогательных устройств для интерпретации контента.
4. Рендеринг происходит с использованием ранее созданных деревьев CSSOM и DOM.

Что происходит при рендеринге страницы?

Инструмент проверки браузера FireFox

Веб- сайты визуализируются с помощью дизайна кода для завершения макета, стиля, рисования и иногда компоновки на веб-сайте. Объектная модель CSS (CSSOM) и объектная модель документа (DOM)

Стиль

DOM и CSSOM объединяются в дерево рендеринга, и начинается построение. Дерево рендеринга упорядочивает видимые узлы, содержимое и вычисляемые стили для сайта и каждого уникального узла.

Макет

Макет — это шаг, на котором архитектура встречается со строительством, и создается структура страницы для отображения ширины, высоты и расположения всех узлов в дереве рендеринга. Для каждого объекта определяются размер и положение.

Веб-сайты выкладываются в виде коробки. Эти поля могут подстраиваться под неограниченное количество различных размеров области просмотра. Когда структура блока изменяется для изменения размера, это называется перекомпоновкой.

Краска: первая краска и первая содержательная краска (FCP)

Момент, когда браузер веб-сайта выполняет рендеринг страницы, называется «первой отрисовкой». First Paint может быть сплошным цветом фона только в зависимости от кода страницы.

First Contentful Paint (FCP) относится к измеримому моменту, когда посетитель веб-сайта может просматривать контент на вашей странице (текст, изображения, видео и т. д.). FCP измеряет от начала загрузки вашей страницы до момента, когда любой контент отображается.

First Paint и FCP — это не то же самое, что быстрая загрузка страницы или высокая производительность, но пользовательский опыт становится значительно более позитивным, когда посетители сайта воспринимают страницу с быстрой загрузкой. Точная настройка ваших первых рисунков, времени загрузки и производительности сайта улучшает восприятие пользователем времени загрузки.

Композитинг

Веб-страницы используют слои, в которых объекты перекрываются для организации структуры.  Композитинг — это когда страница вычисляет порядок вещей для их правильного отображения.

Перекомпоновки вызывают повторную композицию, поскольку позиционирование объекта часто меняется при перекомпоновке.

Что такое ресурсы, блокирующие рендеринг

Сценарии, таблицы стилей и импорт HTML, которые замедляют, задерживают или блокируют отображение браузером контента на веб-сайте, являются ресурсами, блокирующими отображение. Когда люди ссылаются на ресурсы, блокирующие рендеринг, они обычно имеют в виду:

• CSS
• JavaScript в разделе <head>
• Шрифты, загруженные с сервера или из сети доставки контента
• Импорт HTML (устаревшие страницы)

Существует множество CSS и JavaScript, которые не блокируют рендеринг и критически важны для загрузки в самом верху. Расставьте приоритеты в таблицах стилей, чтобы гарантировать, что любой посетитель сайта увидит предполагаемый контент, а не нестилизованный контент или ничего.Что такое JavaScript и CSS, блокирующие рендеринг?

В процессе рендеринга ваш браузер загружает информацию о веб-сайте, сначала просматривая информацию в <head>, включая каждый скрипт.  Все сценарии должны быть запущены по порядку и полностью обработаны, прежде чем страница будет видна в вашем браузере.

Скрипты выстраиваются в очередь, поэтому во время разработки важен порядок скриптов в <head>. В зависимости от кода он может замедлять или препятствовать полной загрузке вашего веб-сайта, и это то, что мы называем блокирующими рендеринг CSS и JavaScript.

Скрипты на вашем веб-сайте WordPress могут исходить из тем, пользовательских работ или плагинов, добавленных для различных функций.

Являются ли изображения блокирующими рендеринг ресурсами?

Если вам интересно, являются ли изображения блокирующими рендеринг ресурсами, то это не так. Размер изображения по-прежнему может вызывать проблемы с загрузкой вашей страницы, но он не должен блокировать рендеринг.

Зачем устранять ресурсы, блокирующие рендеринг?

Скрипты, блокирующие рендеринг, могут замедлить загрузку страниц и испортить впечатление от веб-сайта для ваших посетителей. Восприятие медленного веб-сайта может привести к потере посетителей, если ваш сайт плохо работает.  Низкое удержание посетителей может повлиять на результаты вашей поисковой системы и уменьшить список результатов.

Более низкий рейтинг поисковой оптимизации (SEO) означает сокращение посетителей и потерю потенциального бизнеса. Потеря рейтинга снижает количество посетителей, а плохой сайт снижает удержание посетителей; Ресурсы, блокирующие рендеринг, могут быть огромной проблемой.

Если ваш веб-сайт нацелен на получение высокой оценки Google PageSpeed, понимание ваших ресурсов, блокирующих рендеринг, является ключом к достижению этой цели.

Как устранить ресурсы, блокирующие рендеринг

Серьезное отношение к SEO-рейтингу вашего сайта и пользовательскому опыту означает, что на вашем сайте должны быть обработаны или удалены ресурсы, блокирующие рендеринг. Если вы не создаете свой сайт с нуля, начните тестировать его на наличие ресурсов, блокирующих рендеринг.

После того, как вы определили эти ресурсы, блокирующие рендеринг, вы выберете свой метод решения проблемы и улучшения функциональности вашего сайта.

Проверьте, есть ли на вашем сайте ресурсы, блокирующие рендеринг

Никогда не помешает провести оценку вашего веб-сайта, чтобы обнаружить ресурсы, блокирующие рендеринг (попробуйте Google PageSpeed ​​Insights). Если вы оптимизировали в меру своих возможностей, следуете рекомендациям, но по-прежнему испытываете проблемы или не знаете, с чего начать, оценщики страниц могут быть полезными подсказками.

Методы устранения блокировки рендеринга JavaScript и CSS

WordPress позволяет вам управлять любыми ресурсами, которые мешают отображению вашего сайта, несколькими способами. WordPress позволит вам упорядочить сценарии и ссылки, блокирующие рендеринг, с помощью кода, тегов, организации и оптимизации файлов, а также плагинов.

Профессиональные разработчики также могут создавать собственные плагины или темы, которые встраивают эти процессы в код.

Удалите блокирующий рендеринг Javascript с помощью кода

Три метода устранения ресурсов, блокирующих рендеринг, с помощью кода:

1. Переместите теги <script> и <link> в конец HTML-кода.
2. Добавьте атрибуты async или defer в тег для некритических скриптов.
3. Удалите неиспользуемый код JavaScript.

WordPress загружает файл jQuery Migrate, чтобы обеспечить совместимость со старыми версиями jQuery, используемыми плагинами и темами. Вы можете использовать фрагмент кода или плагин, чтобы запретить WordPress загружать этот файл jQuery Migrate, если ничто на вашем сайте не нуждается в его работе.

Избавьтесь от таблиц стилей, блокирующих визуализацию

Природа таблиц стилей делает их блокирующими рендеринг ресурсов по своей природе. Вы можете решить эту проблему на своем сайте следующими способами:

1. Разделите CSS по типу носителя (мобильный, планшет, рабочий стол и т. д.).
2. Оптимизируйте критический путь рендеринга
3. Объединение файлов CSS

Используя WordPress и визуальный конструктор, вы не можете напрямую контролировать построение страницы, но есть способы обойти любую проблему.

Устранение блокировки рендеринга с помощью плагина или расширения WordPress

Плагины и расширения WordPress используются для организации скриптов на странице.  Плагины будут проходить через теги <script> и <link> вашей страницы и применять атрибуты отсрочки или асинхронности на основе определенных рекомендаций.

Попросите профессионала WordPress устранить ресурсы, блокирующие рендеринг, для вас

Некоторые плагины требуют настройки и, хотя они и кажутся простыми, могут перестать работать при неправильной настройке. Нет ничего постыдного в том, чтобы обратиться за помощью к специалисту по WordPress, и GoHost есть несколько специалистов, которые могут оптимизировать ваш сайт.

Лучшие практики для оптимизации рендеринга

1. Объедините ресурсы, блокирующие рендеринг, чтобы уменьшить их влияние на загрузку страницы.
2. Уменьшите размер ресурса, чтобы уменьшить количество загружаемых байтов.
3. Отложите загрузку ресурсов, не блокирующих рендеринг.
4. Не добавляйте CSS с помощью правила @import, так как это внешняя загрузка.
5. Используйте плагин WordPress, предназначенный для кэширования ваших скриптов и оптимизации JavaScript и CSS.
6. Загружайте пользовательские шрифты локально.
7. Определите критические и некритические CSS и JavaScript.
8. Помечайте некритичный код, блокирующий рендеринг, атрибутами async или defer.
9. Неиспользуемый код следует удалить.

Избавьтесь от головной боли и позвольте профессионалу WordPress помочь

Мы понимаем, почему производительность важна для вашего бизнеса и на каких областях следует сосредоточиться, чтобы добиться наиболее значительного результата.

Улучшение производительности вашего веб-сайта и удобства для посетителей может заключаться не только в ресурсах, блокирующих рендеринг. вы можете просмотреть ваш сайт и адрес:

• Размеры изображений
• Качество изображения и формат доставки
• Длина страницы и процент динамического содержания
• Плохо построенные темы
• Ненужные скрипты, вызывающие задержки
• Плагины, которые плохо построены
• Неиспользуемые внешние скрипты
• Устаревшее программное обеспечение
• Ограниченный план веб-хостинга не может в достаточной мере удовлетворить потребности сайта.

WordPress может быть достаточно простой платформой для создания веб-сайта, но для максимального удобства пользователей может потребоваться обученный профессионал или отличный поставщик услуг.

Часто задаваемые вопросы

• Что такое «устранение ресурсов, блокирующих рендеринг»?

Веб-сайты используют сценарии и ссылки для доступа к файлам и коду для создания веб-сайта в браузере. Иногда скриптам и ссылкам требуется некоторое время для загрузки, что препятствует отображению других частей веб-сайта для посетителя. Устранение ресурсов, блокирующих рендеринг, означает устранение скриптов, ссылок, шрифтов и файлов, которые замедляют или мешают правильной загрузке веб-сайта.

• Как исправить ресурсы, блокирующие рендеринг?

Существуют разные способы исправления ресурсов, блокирующих рендеринг, и ваш выбор будет зависеть от того, что вам нужно решить. Выясните, какие сценарии и ссылки имеют решающее значение для загрузки вашей страницы, а затем отложите остальные до тех пор, пока они не потребуются.

 Приоритизация кода может быть выполнена с помощью кода или с помощью плагина.

• Как мне избавиться от ресурсов, блокирующих рендеринг, на моем веб-сайте?

Если вы используете WordPress, самый простой способ — использовать высококачественный плагин, который управляет вашими сценариями и внешними нагрузками, оценивая, что является критическим, а что можно отложить на потом в процессе рендеринга. Вместо того, чтобы вручную оценивать код и назначать теги каждому скрипту для ручной организации (что все еще возможно и рекомендуется), плагин автоматически обрабатывает это за вас.

• Как исправить/устранить ресурсы, блокирующие рендеринг, без плагина?

Если вы не хотите добавлять еще один плагин на свой веб-сайт или плагин вам не подходит, есть другие способы исправить ресурсы, блокирующие рендеринг. Вы можете вручную оптимизировать любые сценарии и ссылки в коде, чтобы обеспечить их загрузку в правильном порядке или отложить загрузку этого сценария до завершения необходимых функций.

Исправление замечаний PageSpeed Insights — WordPress

#1 Tata_N

Отправлено 13 Июнь 2015 — 09:03

делала адаптивный шаблон, проверяла страницы, получила для мобильных вот такое «исправьте обязательно»:

Цитата

Удалите из верхней части страницы код JavaScript и CSS, блокирующий отображение

Количество блокирующих скриптов на странице: 1.
Количество блокирующих ресурсов CSS на странице: 3.
Они замедляют отображение контента.
Все содержание верхней части страницы отображается только после загрузки указанных далее ресурсов. Попробуйте отложить загрузку этих ресурсов, загружать их асинхронно или встроить их самые важные компоненты непосредственно в код HTML.

Удалите код JavaScript, препятствующий отображению:

сайт. ru/wp-includes/js/jquery/jquery.js?ver=1.3.2

Оптимизируйте работу CSS на следующих ресурсах:

сайт.ru/wp-content/plugins/wp-postratings/postratings-css.css?ver=1.63
сайт.ru/wp-content/plugins/wp-pagenavi/pagenavi-css.css?ver=2.70
сайт.ru/wp-content/themes/fluid-blue/style.css

Подскажите, плиз, о каком скрипте идет речь и что значит блокирующие ресурсы в CSS?

P.S. Кстати, а для адаптивной верстки в плагинах стили тоже надо адаптировать/вставлять
@media screen для разных экранов, если они не очень выглядят ? а как же тогда обновление версий (хотя я их не обновляю)?

Мой «чемодан без ручки»

• Наверх

---

#2 madcap

Отправлено 13 Июнь 2015 — 14:22

Из-за окончаний файлов типа «?ver=1. 63″ могут быть проблемы со сжатием и кэшированием.
Лучше всего, когда ссылки на стили и скрипты отдаются в классическом виде с расширениями .js и .css …

Эти файлы можно объединить в один файл и отдавать с сервера в сжатом виде (хотя возможно на вашей CMS придётся для этого малость попрыгать с бубном):
сайт.ru/wp-content/plugins/wp-postratings/postratings-css.css?ver=1.63
сайт.ru/wp-content/plugins/wp-pagenavi/pagenavi-css.css?ver=2.70

сайт.ru/wp-content/themes/fluid-blue/style.css

А вот это зло:

сайт.ru/wp-includes/js/jquery/jquery.js?ver=1.3.2

Лучше заменить эту строку в шаблоне например на вот эту:
http://yastatic.net/…3/jquery.min.js

Или на любую другую версию, просто заменив цифры в URL. Все версии, доступные на CDN Яндекса можно посмотреть тут — https://tech.yandex.ru/jslibs/
Там ещё и другие библиотеки есть, которые тоже можно использовать. Кэширование этих файлов и сжатие оптимально настроены на сервере раздающем эти скрипты,

Для скриптов и стилей, который Ваш шаблон загружает с Вашего сервера (хостинга) можно так же использовать аттрибут «async». Это по-идее поможет решить предупреждение в PageSpeed. Но при использовании этого аттрибута надо быть предельно осторожными, и учитывать последовательность загнрузки стилей и скриптов, так как при синхронной загрузке некоторые из них могут не запуститься, так как до инициализации загружаемого скрипта не загрузились другие скрипты. Например — Jquery грузится последним, а его плагины загрузились раньше него и при инициализации выдали ошибку.
Вот эту страничку посмотрите — http://htmlbook.ru/html/script/async

Настройка Директ. Дорого. Качественно.

• Наверх

---

#3 c4e8ece0

Отправлено 13 Июнь 2015 — 17:00

Css надо упаковать в один файл, а js грузить перед закрывающим </body>, также для <script> желательно указать атрибут async=»async», чтобы он ничего не лочил и грузился вместе с другими ресурсами.
Каждая вставка <script> в код останавливает обработку нижеследующего кода до своего завершения, поэтому их желательно использовать как можно позже и как можно реже.
Баннерокрутилкам атрибут async=»async» желательно заменить на defer=»defer», чтобы они работали уже по остаточному принципу.
Похожая история и с css — отображение не начинается пока не отработаны все css-файлы.

Но если всё быстро работает — можно забить.

Tata_N сказал:

@media screen для разных экранов, если они не очень выглядят ? а как же тогда обновление версий (хотя я их не обновляю)?

В @media прописываются дополнительно правила для каких-то селекторов. Если в какой-то версии чего-то меняются идентификаторы — то они заносятся дополнительно в эту же секцию.

madcap сказал:

Из-за окончаний файлов типа «?ver=1.63» могут быть проблемы со сжатием и кэшированием. Лучше всего, когда ссылки на стили и скрипты отдаются в классическом виде с расширениями . js и .css …

С точностью до наоборот всё.

«Они не могут ничего, у них лапки котят»
mine.organic

• Наверх

---

#4 madcap

Отправлено 13 Июнь 2015 — 19:41

Дартаньян (13 Июнь 2015 — 17:00) писал:

С точностью до наоборот всё.

По подробнее можно?

Если бы было с точностью до наоборот было — то и Яша отдавал бы файлы со своего CDN с хвоставми и версиями на концах (и не только Яша. Так как Гугл вроде тоже Jquery отдаёт с чистым окончанием «js»).
Ну а если у Вас Nginx, и Вы настраиваете в его сжатие файлов на лету, то Вам нужно указывать расширения файлов, например text/css и т.п.. И если у Вас файлы типа <***.js?ver=58690&y=2>, то ничего не получится, либо настройка будет слишком мудрёной.

Что касается настройки Апача и htaccess, то в них Вам тоже нужно указывать что сжимать, и сколько это должно храниться в кэше браузера.
Небольшой пример части кода:
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript

и т.п.

Так, что в названии файла версию указывать можно. А вот в разрешении файла — не стоит.

Настройка Директ. Дорого. Качественно.

• Наверх

---

#5 c4e8ece0

Отправлено 13 Июнь 2015 — 20:34

Веб-сервера отрабатывают статику по расширению, да, поэтому антикеш стоит дописывается через get-параметры. Get-параметры не являются частью расширения.
CDN же раздаёт всегда продакшен-версию которая не меняется, поэтому для него правильней кодировать её в каталог или файл.
Но если мы отдаём разрабываемое что-то своё, то его старая версия не должна кешироваться наглухо во избежание нехороших «бонусов». А чтобы обходить уродские кешировщики самый простой способ (и стабильный и надёжный) — это гет-параметры и срок хранения в бесконечность.

Итого — вебсервер продолжает паковать файлы и рассылать заголовки, кешировщик кеширует полный путь до файла вместе с get-параметрами, get-параметры обеспечивают пробивание кеша для устаревшей версии скриптов.

«Они не могут ничего, у них лапки котят»
mine.organic

• Наверх

---

#6 Tata_N

TC Отправлено 13 Июнь 2015 — 21:29

Упс. .. все буквы знаю, слова все понимаю, но общий смысл — с большим трудом)) Придется читать какой-то букварь…
была еще ошибка про статичные картинки — я погуглила, и включила кеш на хостинге, срок поставила 1 месяц.

Дартаньян сказал:

Но если всё быстро работает — можно забить.

поменяла блоки адсенса на адаптивные — они асинхронные. Страница грузится быстро, а блоки адсенса — с паузой разной продолжительности, от 1 до 10 сек. Скорость нужно учитывать для всей страницы, включая адсенс?

Мой «чемодан без ручки»

• Наверх

---

#7 c4e8ece0

Отправлено 13 Июнь 2015 — 21:36

Tata_N сказал:

поменяла блоки адсенса на адаптивные — они асинхронные. Страница грузится быстро, а блоки адсенса — с паузой разной продолжительности, от 1 до 10 сек. Скорость нужно учитывать для всей страницы, включая адсенс?

Нет, только родной контент, всё внешнее по умолчанию всегда тупит и ломается.

«Они не могут ничего, у них лапки котят»
mine.organic

• Наверх

---

#8 madcap

Отправлено 14 Июнь 2015 — 22:51

Дартаньян (13 Июнь 2015 — 20:34) писал:

А чтобы обходить уродские кешировщики самый простой способ (и стабильный и надёжный) — это гет-параметры и срок хранения в бесконечность.

Срок хранения файла в кэше равный бесконечности — это по Вашему хороший выход из ситуации? Вам не жалко кэши браузеров у посетителей ваших сайтов? А если мы все так будем кэшировать отдаваемые файлы? У людей же жесткие (и не очень жесткие) диски за месяц забьются мусором. Ну а владельцы мобильных браузеров — вообще не люди получается с их 2-16 гигабайтами SSD. Если бы во времена Сталина был бы интернет — то за такой алгоритм кэширования вполне можно было бы получить сталинскую премию почетное звание врага народа и отправиться туда, где даже летом холодно в польто.

ИМХО. «А чтобы обходить уродские кешировщики» — думаю было бы лостаточно на них не ориентироваться, а двигаться в ногу со временем, создавая сайты и настраивая кэширование под современные и популярные браузеры *(если что — хак для отдельного браузера всегда можно добавить в код, если приспичит). Мы же IE6 уже похоронили? И другие кривые браузеры так же похороним… со временем…

Настройка Директ. Дорого. Качественно.

• Наверх

---

#9 c4e8ece0

Отправлено 14 Июнь 2015 — 23:29

Срач про Украину в другой теме.

«Они не могут ничего, у них лапки котят»
mine.organic

• Наверх

---

Как удалить (или уменьшить) неиспользуемый JavaScript в WordPress

«Удалить неиспользуемый JavaScript» (или последняя версия: « Уменьшить неиспользуемый JavaScript») — одна из самых сложных рекомендаций PageSpeed ​​Insights, с которыми вы можете столкнуться при тестировании своего сайта WordPress. производительность. Он также является одним из самых распространенных, поэтому вы, вероятно, видели его в своем отчете об эффективности.

Давайте разберемся, что означают неиспользуемые файлы JavaScript и как они влияют на производительность. Вы узнаете, как их можно удалить или уменьшить, а также повысить производительность WordPress.

Сначала посмотрите наше видео или просто продолжайте читать нашу статью!

Что такое неиспользуемые файлы JavaScript?

Неиспользуемые файлы JavaScript — это ресурсы, которые не нужны для рендеринга страницы, то есть для загрузки и отображения основного содержимого страницы.

Они могут не понадобиться по двум причинам:

1. Они не являются частью содержимого верхней части страницы — самого важного содержимого, которое необходимо отобразить.
   Чтобы страница загружалась быстрее, браузер должен анализировать и отображать только самые необходимые ресурсы — в основном HTML-код. Кстати, именно поэтому вы должны исключить ресурсы JS и CSS, блокирующие рендеринг, которые замедляют загрузку страницы.

   Типичным примером таких файлов JS является сторонний код, такой как коды отслеживания Google Analytics и Facebook.

   Еще один полезный пример для пользователей WordPress — использование плагинов только при необходимости. Все плагины загружают скрипты, которые в основном основаны на JS. Вот почему вы должны быть осторожны и загружать их только на основные страницы. В противном случае файлы JavaScript сильно повлияют на производительность, и другого простого способа решить проблему не будет. То же самое касается тем и конструкторов страниц, которые сильно зависят от JavaScript.

2. Они есть в коде, но больше не используются . Они совершенно бесполезны.

Почему следует удалять или сокращать объем неиспользуемого JavaScript 

Неиспользуемые файлы JavaScript могут сильно повлиять на производительность вашего сайта и взаимодействие с пользователем. Основной задействованной метрикой является первая задержка ввода (FID), одна из основных метрик Web Vitals.

Задержка первого ввода измеряет скорость отклика страницы с учетом взаимодействия с пользователем, поэтому ее можно рассчитать только в поле.

Total Blocking Time (TBT) заменяет FID в качестве метрики Lighthouse, определяющей интерактивность страницы на основе пользовательского ввода. Метрика TBT составляет 25% оценки производительности Lighthouse. Легко понять, насколько это важно и почему необходимо удалять неиспользуемый JavaScript.

Как мы объясняли, неиспользуемый JavaScript может повлиять на скорость рендеринга и загрузки страницы браузером. И худшее время загрузки страницы тоже нехорошо для пользователей.

Как найти неиспользуемый JS для устранения или сокращения

Существуют различные способы анализа и идентификации файлов JavaScript, о которых следует позаботиться.

Давайте рассмотрим два простых и понятных инструмента: PageSpeed ​​Insights и GTmetrix.

Поиск неиспользуемых JS с помощью PageSpeed ​​Insights

Отчет PageSpeed ​​Insights позволяет очень легко определить неиспользуемый JavaScript, который следует удалить. Перейдите в раздел «Возможности» и найдите «Удалить неиспользуемый JavaScript». Здесь вы узнаете, влияют ли и какие ресурсы JS на производительность вашего сайта. В приведенном ниже примере сценарий JS связан с Диспетчером тегов Google.

Поиск неиспользуемых файлов JS с помощью GTmetrix

Другой способ найти файлы JavaScript — использовать каскадную диаграмму, предоставленную GTmetrix. После тестирования производительности вашего URL-адреса перейдите к каскадной диаграмме и посмотрите на вкладку JS. Там вы найдете список неиспользуемых JS, которыми вы должны управлять.

Как мы упоминали выше, большинство тяжелых JS-скриптов связаны с кодами отслеживания (например, Google Tag Manager) и плагинами. Вы можете легко понять это, взглянув на столбец Домен.

Водопад GTmetrix

Теперь давайте разберемся, как выполнить рекомендацию PSI и разобраться с неиспользуемым JavaScript.

Как удалить или уменьшить неиспользуемые файлы JS в WordPress: два метода

Вы можете удалить или уменьшить неиспользуемые файлы JS двумя способами:

1. Вы можете задержать ресурсы JavaScript . Таким образом, файлы JavaScript будут загружаться только при взаимодействии с пользователем, например при прокрутке или нажатии кнопки. Если взаимодействие с пользователем не происходит, файлы JS вообще не будут загружены.

   Обратите внимание, что не все скрипты из списка рекомендаций PageSpeed ​​можно безопасно задерживать. Вы должны задерживать только файлы JS, которые находятся выше сгиба, потому что они блокируют рендеринг ресурсов.

   Если вы задержите JavaScript, инструмент Lighthouse не обнаружит файлы JS, поскольку они еще не загружены. Вот как вы можете выполнить рекомендацию PSI и гарантировать, что подавляющее большинство файлов не будет включено в отчет.

2. Вы можете загружать файлы JavaScript только при необходимости. Это означает, что JS-скрипты будут выполняться только тогда, когда они нужны определенным страницам. Еще раз, вы можете подумать о плагинах и конкретных темах или компоновщиках страниц, которые вы используете — вероятно, они не будут полезны на всех страницах.

Эти два варианта дополняют друг друга, поскольку каждый из них решает отдельный аспект управления неиспользуемым JS.

С одной стороны, задержка JS будет контролировать время выполнения кода. Технически это обходной путь, а не исправление. Но это имеет свой эффект, поскольку делает JS неблокирующим рендеринг.

С другой стороны, выгрузка ненужных ресурсов уменьшит размер JS на странице. Технически это сокращает неиспользуемый JS, а не полностью удаляет его.

Примечание: даже такими методами трудно избавиться от уведомления PageSpeed ​​Insights. Lighthouse отмечает любой файл, содержащий более 20 КБ неиспользуемого кода JS.

Поскольку большинство тем и плагинов поставляются с JS-файлами в комплекте, весьма вероятно, что во многих файлах указанный выше лимит будет превышен. Другими словами, сочетание JS почти гарантирует, что вы всегда будете показывать рекомендацию.

Вот почему в большинстве случаев конечной целью является уменьшение эффекта от удаления неиспользуемого JS, а не его полное исправление.

Хорошим примером является библиотека jQuery, когда ее нельзя отложить. Он всегда будет помечен как неиспользуемый JS.

Удаление или сокращение неиспользуемых ресурсов JS с помощью подключаемых модулей

У вас есть различные варианты удаления или сокращения неиспользуемого JavaScript с помощью подключаемых модулей.

Если вы хотите отложить выполнение файлов JavaScript, вы можете использовать функцию задержки выполнения JavaScript, предоставляемую WP Rocket.

Опция проста в использовании и поможет вам сэкономить массу времени и усилий!

На вкладке «Оптимизация файлов» перейдите к параметру «Отложить выполнение JavaScript» и отметьте его. Вам не нужно буквально ничего делать.

WP Rocket позаботится обо всем, и вы увидите очевидную разницу в вашей оценке производительности и отчете PSI.

Получите WP Rocket прямо сейчас и протестируйте улучшения прямо сейчас!

Еще один способ отложить JS-файлы — использовать плагин, такой как Flying Scripts или WP Meteor.

С другой стороны, вы можете использовать подключаемый модуль управления активами для управления тем, где будут загружаться определенные файлы , например: 

• Очистка активов
• Permatters
• Gonzales
• Организатор плагинов.

Начните удаление неиспользуемого JavaScript прямо сейчас

Удаление или сокращение количества неиспользуемого JavaScript является важным шагом для оптимизации оценки FID и повышения производительности вашего сайта, а также для достижения 100%-го результата в Google PageSpeed ​​Insights!

Благодаря WP Rocket вы можете легко управлять неиспользуемыми JS и решать проблемы с производительностью.

Еще не клиент WP Rocket? Сэкономьте свое время и позвольте WP Rocket сделать всю работу за вас. WP Rocket — это самый простой способ улучшить свой показатель PageSpeed ​​Insights.

Вы всегда можете рассчитывать на нашу 100% гарантию возврата денег . Хотя мы не думаем, что он вам когда-нибудь понадобится, мы с радостью вернем вам деньги, если вы запросите его в течение 14 дней с момента покупки.

🚀 Единственный риск, которому вы подвергаетесь с нашим плагином, — это ускорение вашего сайта. WP Rocket автоматически применяет 80% передовых методов веб-производительности, мгновенно повышая ваши показатели Core Web Vitals.

Как исправить код JavaScript и CSS, блокирующий рендеринг, в WordPress

Вы хотите устранить код JavaScript и CSS, блокирующий рендеринг, в WordPress?

Если вы протестируете свой веб-сайт с помощью Google PageSpeed ​​Insights, то, скорее всего, увидите предложение удалить скрипты, блокирующие рендеринг, и CSS. Однако в нем нет подробностей о том, как это сделать на вашем сайте WordPress.

В этой статье мы покажем вам, как легко исправить JavaScript и CSS, блокирующие рендеринг, в WordPress, чтобы улучшить ваш показатель Google PageSpeed.

Что такое JavaScript и CSS, блокирующие рендеринг?

Блокировка рендеринга JavaScript и CSS — это файлы, которые не позволяют веб-сайту отображать веб-страницу до загрузки этих файлов.

Каждый сайт WordPress имеет тему и плагины, которые добавляют файлы JavaScript и CSS во внешний интерфейс вашего сайта. Эти скрипты могут увеличить время загрузки страницы вашего сайта, а также могут блокировать отрисовку страницы.

Браузер пользователя должен будет загрузить эти сценарии и CSS перед загрузкой остальной части HTML на странице. Это означает, что пользователям с более медленным соединением придется подождать еще несколько миллисекунд, чтобы увидеть страницу.

Эти сценарии и таблицы стилей называются блокирующими рендеринг JavaScript и CSS.

Владельцам веб-сайтов, которые пытаются получить 100 баллов Google PageSpeed, необходимо исправить эту проблему, чтобы получить этот высший балл.

Что такое Google PageSpeed ​​Score?

Google PageSpeed ​​Insights — это инструмент для проверки скорости веб-сайтов, созданный Google для помощи владельцам веб-сайтов в оптимизации и тестировании своих веб-сайтов. Этот инструмент проверяет ваш сайт на соответствие рекомендациям Google по скорости и предлагает предложения по улучшению времени загрузки страницы вашего сайта.

Он показывает вам оценку, основанную на количестве правил, которым соответствует ваш сайт. Большинство веб-сайтов получают где-то между 50-70. Тем не менее, некоторые владельцы веб-сайтов считают необходимым набрать 100 баллов (самый высокий балл, который может получить страница).

Вам действительно нужна идеальная оценка Google PageSpeed ​​«100»?

Цель Google PageSpeed ​​Insights — предоставить вам рекомендации по повышению скорости и производительности вашего веб-сайта. Вы не обязаны строго следовать этим правилам.

Помните, что скорость — это только один из многих SEO-показателей веб-сайта, которые помогают Google определить рейтинг вашего сайта. Причина, по которой скорость так важна, заключается в том, что она улучшает взаимодействие с пользователем на вашем сайте.

Для лучшего взаимодействия с пользователем требуется гораздо больше, чем просто скорость. Вы также должны предлагать полезную информацию, лучший пользовательский интерфейс и привлекательный контент с текстом, изображениями и видео.

Ваша цель должна состоять в том, чтобы создать быстрый веб-сайт, который предлагает отличный пользовательский интерфейс.

Во время последнего редизайна WPBeginner мы сосредоточились на скорости, а также на улучшении взаимодействия с пользователем.

Мы рекомендуем вам использовать правила Google Pagespeed в качестве рекомендаций, и если вы можете легко их реализовать, не нарушая работу пользователей, то это здорово. В противном случае вы должны стремиться сделать как можно больше, а об остальном не беспокоиться.

Сказав это, давайте посмотрим, что вы можете сделать, чтобы исправить код JavaScript и CSS, блокирующий рендеринг, в WordPress.

Мы рассмотрим два метода, которые исправят код JavaScript и CSS, блокирующий рендеринг, в WordPress. Вы можете выбрать тот, который лучше всего подходит для вашего сайта.

1. Исправление сценариев блокировки рендеринга и CSS с помощью WP Rocket

Для этого метода мы будем использовать плагин WP Rocket. Это лучший плагин кэширования WordPress на рынке, который позволяет быстро повысить производительность вашего сайта без каких-либо технических навыков или сложной настройки.

Во-первых, вам необходимо установить и активировать плагин WP Rocket. Для получения более подробной информации см. наше пошаговое руководство по установке плагина WordPress.

WP Rocket работает из коробки и включит кеширование с оптимальными настройками для вашего сайта. Вы можете узнать больше об этом в нашем полном руководстве о том, как правильно установить и настроить WP Rocket в WordPress.

По умолчанию не включает параметры оптимизации JavaScript и CSS. Эти оптимизации потенциально могут повлиять на внешний вид вашего веб-сайта или некоторые функции, поэтому плагин позволяет вам включить эти настройки по желанию.

Для этого вам нужно посетить Настройки »Страница WP Rocket , а затем перейдите на вкладку «Оптимизация файлов». Отсюда прокрутите до раздела «Файлы CSS» и установите флажки рядом с параметрами «Минимизировать CSS», «Объединить файлы CSS» и «Оптимизировать доставку CSS».

Примечание: WP Rocket попытается минимизировать все ваши файлы CSS, объединить их и загрузить только те CSS, которые необходимы для видимой части вашего сайта. Это может повлиять на внешний вид вашего веб-сайта, поэтому вам необходимо тщательно протестировать его на разных устройствах и размерах экрана.

Далее вам нужно перейти к разделу «Файлы JavaScript». Отсюда вы можете проверить все параметры для максимального повышения производительности.

Вы можете минимизировать и комбинировать файлы JavaScript, как вы это делали для CSS.

Вы также можете запретить WordPress загружать файл jQuery Migrate. Это скрипт, загружаемый WordPress для обеспечения совместимости плагинов и тем, использующих старые версии jQuery.

Большинству веб-сайтов этот файл не нужен, но вы все равно хотели бы проверить свой веб-сайт, чтобы убедиться, что его удаление не повлияет на вашу тему или плагины.

Затем прокрутите немного вниз и установите флажки рядом с параметрами «Загрузить отложенный JavaScript» и «Безопасный режим для jQuery».

Эти параметры задерживают загрузку несущественных JavaScript, а безопасный режим jQuery позволяет вам загружать jQuery для тем, которые могут использовать его встроенно. Вы можете оставить эту опцию неотмеченной, если уверены, что ваша тема нигде не использует встроенный jQuery.

Не забудьте нажать кнопку «Сохранить изменения», чтобы сохранить настройки.

После этого вы также можете очистить кеш в WP Rocket, прежде чем снова протестировать свой сайт с помощью Google Page Speed ​​Insights.

На нашем тестовом сайте мы смогли набрать 100% баллов на ПК, и проблема блокировки рендеринга была решена как для мобильных устройств, так и для ПК.

2. Исправление сценариев блокировки рендеринга и CSS с помощью Autoptimize

Для этого метода мы будем использовать отдельный плагин, созданный специально для улучшения доставки файлов CSS и JS вашего веб-сайта. Хотя этот плагин выполняет свою работу, у него нет других мощных функций, которые есть у WP Rocket.

Первое, что вам нужно сделать, это установить и активировать плагин Autoptimize. Для получения более подробной информации см. наше пошаговое руководство по установке плагина WordPress.

После активации вам необходимо посетить страницу Settings » Autoptimize , чтобы настроить параметры плагина.

Во-первых, вам нужно установить флажок рядом с опцией «Оптимизировать код JavaScript» в блоке «Параметры JavaScript». Убедитесь, что опция «Объединить JS-файлы» не отмечена.

Затем прокрутите вниз до поля «Параметры CSS» и установите флажок «Оптимизировать код CSS». Убедитесь, что опция «Объединить CSS-файлы» не отмечена.

Теперь вы можете нажать кнопку «Сохранить изменения и очистить кэш», чтобы сохранить настройки.

Протестируйте свой веб-сайт с помощью инструмента Page Speed ​​Insights. На нашем демонстрационном сайте мы смогли решить проблему блокировки рендеринга с помощью этих базовых настроек.

Если все еще есть сценарии, блокирующие рендеринг, вам нужно вернуться на страницу настроек плагина и просмотреть параметры как в параметрах JavaScript, так и в параметрах CSS.

Например, вы можете разрешить подключаемому модулю включать встроенный JS и удалять сценарии, которые исключены по умолчанию, например, seal. js или jquery.js.

Нажмите кнопку «Сохранить изменения и очистить кеш», чтобы сохранить изменения и очистить кеш плагинов.

Когда вы закончите, снова проверьте свой веб-сайт с помощью инструмента Page Speed.

Как это работает?

Автооптимизация объединяет все поставленные в очередь JavaScript и CSS. После этого он создает мини-файлы CSS и JavaScripts и доставляет кешированные копии на ваш сайт как асинхронные или отложенные.

Это позволяет исправить проблему со сценариями и стилями, блокирующими рендеринг. Однако имейте в виду, что это также может повлиять на производительность или внешний вид вашего веб-сайта.

Устранение неполадок

В зависимости от того, как плагины и ваша тема WordPress используют JavaScript и CSS, может быть довольно сложно полностью устранить все проблемы JavaScript и CSS, блокирующие рендеринг.

Хотя вышеперечисленные инструменты могут помочь, вашим плагинам могут потребоваться определенные скрипты с другим уровнем приоритета для правильной работы.