Слишком много css или js файлов wordpress
Когда ко мне пришла идея создания канала « YouGo в Яндекс.Дзен » – я решил, что буду выкладывать в Дзене полезную, но сжатую информацию, а на сайте развернутую и оптимизированную под поисковые системы.
И к тому времени, как я его полностью сверстал – у меня появилась необходимость оптимизировать верстку для того, чтобы она стала максимально легкая и соответственно, – супер суперскоростная.Удаление, оптимизация и gzip-сжатие лишнего CSS и JS-кода на сайте. Удаление, оптимизация и gzip-сжатие лишнего CSS и JS-кода на сайте.
К сожалению ни в Google, ни в Yandex я не нашел информацию о том, как удалить лишний CSS и JavaScript. Тогда я спросил у разработчиков на одном форуме и они мне подсказали о том, что подобного рода задачу можно решить с помощью консоли Google Chrome .
Поэтому в этой статье, я хочу рассказать вам о том, как мне удалось удалить лишний CSS и JavaScript-код , а также о том, как его, сжать, потом еще раз сжать на сервере, оптимизировать и закэшировать.
1. Ищем и удаляем лишний CSS и JS-код
Зайдите на свой сайт через браузер Google Chrome и нажмите F12 , затем меню -> More tools -> Coverage .
Затем, перед вами будет вот такая картина, где вам нужно будет выбрать 2-ой вариант для того, чтобы оптимизировать нужный файл на сайте:
Второй вариант обновит страницу для того, чтобы сбросить кэш. Второй вариант обновит страницу для того, чтобы сбросить кэш.Нажимаем: Click the reload button to reload and start capturing coverage и вы выбираем файл, из которого собираемся удалить все лишние.
Выберите на абсолютно любой файл, который собираетесь оптимизировать и нажмите крестик ( Close drawer ).
Здесь нужно нажать крестик для того, чтобы увидеть лишний CSS-код. Здесь нужно нажать крестик для того, чтобы увидеть лишний CSS-код.Обратите внимание, строчки кода, которые слева подсвечены красным – означают то, что данные классы не используется на странице, а те, что зеленым – означают, что используются.
Важно! Не удаляйте лишний CSS и JS-код прямо в самих файлах – это займет огромное количество времени.
Вместо этого – просто откройте блокнот и вставьте в него все, что подсвечено зеленым. Ну, а далее скопируйте все его содержимое и вставьте в нужный CSS или JS-файл.
2. Оптимизируем CSS и JavaScript-файлы
В интернете имеется огромное количество веб-сервисов, с помощью которых можно решить данную задачу. Также есть куча инструментов на GitHub, но не все ими смогут воспользоваться т. к. нужно знать Node.js.
Но мы не будем на этом заморачиваться в то время, когда существуют следующие превосходные сервисы, решающие подобного рода задачи:
- FreeFormatter – выравнивает, оптимизирует, преобразовывает HTML , CSS , JavaScript , XML , SQL и многое другое.
- CSSO – сжимает и выравнивает CSS-код без потери валидации.
- JavaScriptCompressor – сжимает скрипты без потери валидации.
- HTML Minifier – просто сжимает HTML-код .
Ну, а далее можно еще включить кэширование и gzip-сжатие для наших CSS и JavaScript-файлов. Для этого просто вставьте следующий код в файл .htaccess , который обычно находиться в корневой директории сайта:
ExpiresByType application/x-shockwave-flash "access plus 2592000 seconds"
ExpiresByType text/javascript "access plus 604800 seconds"
ExpiresByType application/javascript "access plus 604800 seconds"
ExpiresByType application/x-javascript "access plus 604800 seconds"
ExpiresByType application/xhtml+xml "access plus 600 seconds"
Вышеприведенным кодом мы закэшировали наш сайт, теперь давайте еще сожмем наши CSS и JavaScript-файлы с помощью следующего кода, который также нужно вставить в файл .htaccess :
AddOutputFilterByType DEFLATE application/javascript
Подведем итоги в заключение
Ради эксперимента – проверьте сейчас свой сайт в PageSpeed и потом повторно после проведения всех вышеописанных процедур.
Скорость сайта должна взлететь, но это еще не все – в следующей статье я расскажу вам про оптимизацию картинок, формат WebP и многое другое.
Если папка cache/min слишком велика из-за необычно большого количества файлов JS, это может вызвать проблемы:
- Занимает слишком большую дисковую квоту в вашей учетной записи хостинга
- Слишком много файлов означает, что иногда старые не удаляются полностью
Когда количество JS-файлов слишком велико, это обычно связано с динамическим встроенным JavaScript на вашем сайте. Начиная с WP Rocket 3.1, когда активирована опция объединения JS, встроенные скрипты JS также оптимизируются путем включения их в объединенный файл JS.
Что такое «Dynamic Inline JS»?
В этом контексте «динамический» означает контент, который меняется от страницы к странице. Динамический встроенный JS означает, что один и тот же сценарий присутствует на многих страницах вашего сайта, но одна небольшая часть меняется от страницы к странице. Это приведет к созданию нового комбинированного файла JS для каждой страницы. На сайте с большим количеством страниц это быстро создаст слишком много файлов JS.
Вот пример части встроенного скрипта:
Этот же сценарий будет на каждой странице продукта вашего сайта, но детали, такие как идентификатор продукта, имя, категория и цена, будут разными для каждого продукта, что потребует нового файла JS для каждого продукта на вашем сайте.
Чтобы вызвать проблему, достаточно одного символа в сценарии, чтобы он отличался на странице.
Решение состоит в том, чтобы исключить такие скрипты из добавления в объединенный JS-файл.
Как найти встроенный JS для исключения
Чтобы определить, какие скрипты являются динамическими, мы должны сравнить 2 из объединенных файлов JS, созданных WP Rocket, и найти различия. Это приведет нас к сценариям, которые нужно исключить.
Активируйте WP Rocket с включенной опцией Combine JS.
Перейдите в Просмотр> Источник страницы и найдите объединенный файл JS, созданный WP Rocket. Он будет ближе к нижней части источника страницы, а URL-адрес будет иметь следующий формат: /cache/min/1/734613487895454.js Вот пример:
СОВЕТ. Выполните «Найти» (Mac: Command + F, ПК: CTRL + F) для cache / min или .js, чтобы сузить поиск11. Проверьте, отличаются ли объединенные файлы .js, посмотрев на имена файлов. Если имена файлов отличаются, мы знаем, что существует проблема.
- Щелкните файл JS из источника страницы
- Выберите весь JS (Mac: Command + A, ПК: CTRL + A), затем скопируйте содержимое
- Вставьте содержимое на unminify . com , затем нажмите Unminify.
Повторите шаг 5 для второй страницы, которую вы открыли на шаге 2. Затем возьмите неминифицированное содержимое и вставьте его в текстовое поле Changed с правой стороны в Diffchecker:
Щелкните ” Найти отличия”. Подождите минуту или около того, чтобы обработать разницу. Затем вы увидите параллельное сравнение кода с выделенными изменениями. Нажмите на красную / зеленую полосу справа, чтобы перейти непосредственно к различным частям кода. Конкретные изменения будут выделены более темным оттенком красного / зеленого. Теперь вы должны увидеть отдельные части кода, которые отличаются:
В этом примере длинная строка цифр / букв различается на каждой странице. Вероятно, он уникален на каждой странице, и в этом проблема.
Затем нам нужно выбрать строку, которая исключает скрипт в WP Rocket. Это должно быть что-то уникальное для этого сценария, которое будет присутствовать в каждом случае. В этом примере хорошим кандидатом для идентификации этого сценария будет: ct_input_name
Введите это в параметр WP Rocket: Excluded Inline JavaScript.
Если в папке min уже было слишком много файлов JS для автоматического удаления вашим сервером, возможно, вам придется вручную удалить их через FTP. После того, как будут сделаны правильные исключения, файлы будут удалены как обычно, автоматически.
В это статье мы расскажем как оптимизировали конкретное Wordpress веб приложение. Какие действия были выполнены чтобы попасть из красной зоны оценки PageSpeed Insights в зеленую, тут будет мало общих рекомендаций универсальных для любых платформ и приложений, которыми пестрит поисковая выдача, a большe описание действий, которые повлияли на результат в рамках конкретной задачи.
PageSpeed Insights — противоречивый инструмент по оптимизации скорости загрузки веб страниц от Google, который за свою семилетнюю историю много раз менял свои алгоритмы, интерфейсы, все время дорабатывался, нещадно хейтился и даже закрывался, но в 2021 году по прежнему более чем актуален и находится в особом почете и уважении у SEO специалистов. И вовсе не потому что является самым объективным и точным, есть много других отличных инструментов 1, 2, 3, а потому что за ним стоит сам “великий и ужасный” Google.
Итак, у нас задача оптимизировать сайт на CMS Wordpress до зеленой зоны.
Сайт несложный с обычной судьбой, был сверстан под нужды заказчика и натянут на wp+woocommerce, в процессе нагружен 40+ плагинами ( что для сайтов на wp обычное дело ).
PSInsights оценивает ваш сайт отдельно для мобильных и десктопных устройств и делит их на три зоны.
- 0–49 — красная
- 50–89 — желтая
- 90–100 — зеленая
Изначально наш сайт имеет такие грустные оценки.
Для тех кто хочет 100/100
Эта статья для вас не подойдет, можно поискать в разделе фантастика, если такой есть на хабре. Современные сайты, а тем более сделанные на CMS обвешаны огромным количеством js и css библиотек, в случае с WP — это почти всегда много плагинов, каждый из которых может что-то добавлять свое на ваш фронт, все это делает сайт огромной неповоротливой махиной и ждать от нее космических скоростей не стоит.
Хотя пустая установка стандартной темы WP twentytwentyone еще выдает желаемую сотню.
Но если помимо этого вы ещё захотите добавить на страницу хоть что-то, то это что-то будет нуждаться в оптимизации.
Этапы оптимизации
- Удалим лишние плагины.
- Поработаем с изображениями.
- Сократим количество js и css на страницах.
- Специфические оптимизации для конкретного проекта.
Удалим лишние плагины
Современный WP это зоопарк различных плагинов, каждый из них это отдельный мир и экосистема. Любой плагин потенциально может добавлять свой функционал на фронт, даже если изначально он задуман только для административной части сайта. Изучать код всех плагинов и оценивать потенциальную угрозу для производительности займет слишком много времени, поэтому действуем от простого к сложному. Удаляем по максимуму все плагины, доводим сайт до нужной зеленой отметки и потом ставим по одному обратно, отслеживая как каждый из них влияет на оценку PSInsights, если влияние присутствует, то думаем над заменой плагина аналогом или отказаться от него.
В нашем случае мы удалили 22 из 40 плагинов и наши цифры чуть повеселели, хотя по прежнему далеки от поставленной цели.
Поработаем с изображениями
Наш проект имеет три разных предупреждения касающихся изображений на сайте.
- Настройте эффективную кодировку изображений.
- Используйте современные форматы изображений.
- Настройте подходящий размер изображений.
К сожалению это три разных проблемы и одной серебряной пули, которая решит все скопом я найти не смог. Поэтому решаем их поэтапно.
Этап 0. Добавим lazy load для изображений
PSInsights оценивает только те изображения, которые смог увидеть, так зачем ему видеть лишнее? Давайте отложим загрузку изображений, которые находятся ниже начальной загрузки экрана.
WP версии 5.4 добавил поддержку lazy load изображений из коробки, в теории просто добавляем атрибут loading="lazy" к тегу изображений и должно работать, на практике для PSInfights срабатывает не всегда, поэтому ставим плагин autoptimize, который нам еще пригодится ниже для оптимизации js и css кода, и активируем в нем lazy load загрузку изображений.
Этап 1. Настройте эффективную кодировку изображений
По факту это значит что изображения недостаточно оптимизированы.
У PSInsights свой алгоритм по которому он определяет что такое достаточно. К сожалению, все топовые плагины оптимизации изображений до конца не могут оптимизировать изображение под их алгоритм.
Я воспользовался этим решением, оно позволяет в бесплатной версии оптимизировать все изображения сразу по нажатию одной кнопки. У нас еще могут остаться предупреждения про кодировку после этого, но вес основной части изображений будет меньше.
Этап 2. Используйте современные форматы изображений
Тут все не так просто, взять и заменить форматы изображений на webp скопом не получиться, поддержка этого формата браузерами все еще оставляет желать лучшего.
Для конвертации всех изображений в webp формат я воспользовался этим плагином, который в папке uploads рядом с существующими изображениями создает новые с расширением webp. То есть, если раньше у вас было изображение foo.jpg, то сейчас рядом с ним появилось foo.jpg.webp
В теории в таких плагинах есть настройка, которая сама подменяет изображения на webp и показывает нужный формат в зависимости от браузера, на практике у меня предупреждения про формат все равно остались даже после активации настройки.
Поэтому, в тех местах где lazy load не смог скрыть изображения, я вручную заменил тег img на тег picture, как это работает хорошо описано тут.
Код замены привожу ниже, все php переменные естественно должны быть объявлены перед тегом.
Этап 3. Настройте подходящий размер изображений
Это предупреждение появляется если вы пытаетесь загрузить изначально очень большое изображение, а показываете его как маленькое. Тут опять действовать придется точечно и в тех местах где lazy load не смог скрыть изображения, пробовать подключать другие размеры картинок из существующих.
На практике может оказаться так, что существующих недостаточно, тогда придется еще создавать свои отдельные. Для этого объявляем новый размер в functions.php вашей темы.
Затем любым плагином, который может ресайзить изображения, создаем новые размеры и подгружаем их в тег picture, который вы вставляли выше.
После проведенных оптимизаций с изображениями, наши балы заметно повеселели, а для десктопа мы уже попали в желаемую зеленую зону.
Переходим к следующему этапу оптимизации.
Сократим количество js и css на страницах
У нас осталась группа рекомендаций по оптимизации скорости загрузки, все из них относятся к js и css файлам.
- Уменьшите размер кода JavaScript
- Удалите неиспользуемый код CSS
- Удалите неиспользуемый код JavaScript
- Устраните ресурсы, блокирующие отображение
Как видим основные рекомендации это размер js и css библиотек. Нужно определить кто эти библиотеки нам на фронт добавляет. Открываем вкладку network панели хрома, выбираем отображение только js файлов, затем обновляем страницу через ctrl + F5. После этого сортируем по размеру файлов, чтобы выявить самые тяжелые, от которых потенциально исходит самая большая угроза.
В итоге видим что самые тяжелый файл нам добавляют:
- Плагин оператора сайта
- Сервисы статистики и аналитики ( facebook pixel, google tag manager)
- Стандартные библиотеки (jquery, bootstrap)
К сожалению лишние тут выявить сложно, современный веб ресурс сложно представить без этих сервисов, но тем не менее что-то мы должны предпринять.
Отключаем плагин оператора, он добавляет критично много, его в дальнейшем на продакшене либо заменим на другой, либо добавим таймаут на загрузку.
Следующий потенциальный враг это фейсбук пиксель, добавляем таймаут на его загрузку, да наверное это может сказаться на объективности его данных в дальнейшем, но тут уже нужно искать компромисс, что вам больше нужно, скорость загрузки ресурса или объективность данных этого сервиса.
Также отключаем всякие мелочи по типу эмоджи wp, которыми мы не пользуемся на нашем фронте
После этого останется устранить ресурсы блокирующие отображение.
Если все ваши стили и скрипты в теме и плагинах подключены правильно через wp_enqueue_style и wp_enqueue_script соответственно, то устранить блокировку поможет ранее установленный плагин autoptimize, просто активируйте соответствующие галочки.
После этого может возникнуть проблема с отображением ресурса в первые секунды загрузки, для этого нужно критично важный css отображать выше. В нашем случае мы просто возмем из bootstrap.css часть стилей отвечающих за отображение сетки и добавим их в соответствующее окно настроек.
Под капотом плагин соберет все подключаемые файлы js и css в два больших файла, минифицирует их и отдаст на фронт.
После оптимизаций связанных с js и css наши цифры стали совсем близки к цели.
У нас 80+ для мобильных, и стабильно зеленая зона для десктопа.
Предупреждения по сокращению размеров js и css кода по прежнему висят, но их мы больше оптимизировать не будем, потому-что это будет очень трудозатратно по времени, и не нужно в рамках нашей задачи.
Остался последний рывок и тут уже не обойтись без специфических оптимизаций для конкретного проекта.
Специфические оптимизации для конкретного проекта
На самом деле такие спец оптимизации мы уже приводили выше, все проекты уникальны по своему и в вашем ошибки выдаваемые PSInsights могут существенно отличаться, тогда вам нужно вырабатывать свой алгоритм их решения.
В нашем случае для финальной оптимизации мы обратим внимание на результаты “Имитация загрузки страницы”, эти параметры очень важны. Нужно понимать что вы можете выполнить все рекомендации из раздела “Оптимизация” и “Диагностика”, но если при этом параметры имитации загрузки страницы остаются в красной зоне, то высоких оценок вы все равно не получите. Ваш сайт должен стать реально быстрее в процессе оптимизации, согласитесь что это довольно справедливое требование.
Итак в рамках нашего проекта мы видим, что одним из факторов отмеченных красным является “Largest content paint”
Логически глядя на страницу можно легко догадаться какой элемент является самым большим на странице, в нашем случае есть подозрение, что это верхний слайдер запускаемый slick библиотекой. Но мы не будем полагаться только на интуицию, а доверимся инструментам. Открываем панель хрома, вкладку “Performance” и запускаем тест, затем кликаем по кладке “LCP”. В итоге виновник найден. Подозрения подтвердились — это наш верхний слайдер.
При загрузке страницы юзеру неважно слайдером будет наше первое изображение изначально или картинкой. Поэтому для решения проблемы мы заменяем слайдер на картинку, ждем полной загрузки страницы и затем запускаем скрипт инициализации слайдера, а после этого прячем изображение.
В коде это будет выглядеть примерно так. Добавляем параллельно c html слайдера тег изображения и вставляем в его src первое изображение слайдера
Затем в js помещаем инициализацию слайдера в таймаут и скрываем изображением после инициализации
После этих оптимизаций юзер видит при загрузке вначале изображение, a потом через время слайдер. PSInsights видит только изображение, которое грузится гораздо быстрее чем весь слайдер. В итоге все счастливы и наши балы оценки сияют зелеными цифрами.
Подведем итоги. Задача выполнена, все страницы нашего проекта в зеленой зоне. Конечно еще можно провести много всякий оптимизаций:
- Сократить bootstrap.css оставив только нужные элементы.
- Попрофилировать ресурс в поисках узких мест загрузки php и sql запросов.
- Настроить более эффективно кэширование.
И еще много чего, но на сегодня цель достигнута, сайт действительно стал грузиться быстрее и PSInsights оценивает его высоко.
В этом посту будет подразумеваться, что вы знакомы с инструментом Google по оптимизации скорости загрузки страниц сайта — PageSpeed Insights. Слушайте, да прямо сейчас вбейте туда свой сайт нажмите кнопку «Analize».
Окей, а теперь — о чём этот пост?
Вполне возможно, что в результатах проверки вашего сайта есть пункт «Eliminate render-blocking JavaScript and CSS in above-the-fold content».
Я заметил, что этот пункт один из самых трудноразрешимых (трудоёмких) и практически на всех сайтах, даже на очень быстрых, он присутствует.
- Объединяем все JavaScript файлы и размещаем то, что получилось перед закрывающим тегом </body> сайта.
- Объединяем все CSS, суём прямо перед JavaScript, которые мы уже переместили, затем выбираем из них те стили, которые необходимы для корректного отображения страницы, а в особенности её верхней части (первого экрана) и помещаем их в тег <style> в <head> сайта.
Как же обстоит дело на практике, и в данном конкретном случае — для сайтов на WordPress?
1. Воспользуемся зависимостью других скриптов от jQuery
В корректно состряпанной теме WordPress все CSS и JS файлы подключаются через wp_head() и wp_footer() — то есть в <head> и в конце </body> соответственно.
Также у файлов есть зависимости, то есть например плагин fancybox.js должен подключаться после jquery.js , а это значит, что если библиотека jQuery находится в wp_footer(), то FancyBox ну никак не может попасть в wp_head().
Перемещаем jQuery в футер сайта
Делается это очень просто — при помощи функций wp_deregister_script(), wp_register_script(), wp_enqueue_script() и хука wp_enqueue_scripts (иногда используют хук init в связке с is_admin()). Всё, что требуется от вас, это вставить код следующего содержания в файл functions.php вашего сайта.
Хочу обратить ваше внимание на то, что это автоматизированное решение, и хотя оно работает практически в 100% случаев, бывает такое, что некоторые скрипты не хотят переноситься в футер сайта. Тогда уже потребуется более внимательный к каждому вашему файлу JavaScript.
На этом наша работа с JS заканчивается, конечно прирост в скорости даст ещё и объединение скриптов (то есть снимаете их все с регистрации и потом просто подключаете свою объединенную версию) — но Google сейчас это уже не требует.
2. Объединение CSS в WordPress
Если объединение всех JavaScript в один файл — не всегда хорошая идея, то CSS-ки я бы рекомендовал объединять по возможности всегда.
Помните скриншот в самом начале статьи (10 blocking CSS resources)? Откуда берется такое количество файлов стилей, ведь разработчик темы наверное понимал, что делает?
Ответ — из плагинов.
Давайте пошагово разберем как.
Также иногда при помощи условных тегов файлы плагинов (как CSS, так и JS) отключают только с тех страниц, на которых они не используется.
Ок, с «Contact Form 7» разобрались, а как узнать ID файлов CSS других плагинов?
Да легко, открываем исходный код страницы и видим там подобную картину:
Если у вас остались вопросы, либо я забыл упомянуть о чем-либо в этой статье, пожалуйста, оставьте свой комментарий.
Ещё про ускорение сайта
Впервые познакомился с WordPress в 2009 году. Организатор и спикер на конференциях WordCamp. Преподаватель в школе Нетология.
Если вам нужна помощь с сайтом или разработка с нуля на WordPress / WooCommerce — пишите. Я и моя команда будем рады вам помочь!
Комментарии — 27
вообще да проблема с этими джаваскриптами и цсс, чуть ли не каждый плагин норовит впихнуть по файлу а то еще и шрифты подключает. а если уж посмотреть современные темы вордпресс - то там вообще миллион файлов цсс, джава, шрифты.
а еще некоторые плагины пихают в код между хеадер и боди цсс код напрямую.
вообще не понимаю почему все это происходит. никто из разрабов не заботится о том что внутри, лишь бы снаружи было красиво?
ну это ладно. сам использую наподобие функции true_peremeshhaem_jquery_v_futer и вот что странно. я хотел сначала вообще отключить два стандартных вордпрессовских джаваскрипта, использовал эту функцию и прописал вместо
тоесть пустое место. но тогда вообще весь jquery перестал загружаться (от плагинов в том числе).
в итоге понадобился всетаки 1 библиотека мне и оставил ее.
причем некоторые решения ведь требуют загрузку библиотеки перед скриптом? это так? а то у меня сейчас висит в хеадере 1 джаваскрипт в итоге.
а вот еще допустим яндекс карты не загружаются если подключение библиотеки после блока карты идет. так что все в подвал не запихнуть, а хотелось бы.
кстати на самом сайте контактной формы в факе написан такой код для отключения джаваскрипта и цсс
Читайте также: