В этом посту будет подразумеваться, что вы знакомы с инструментом Google по оптимизации скорости загрузки страниц сайта — PageSpeed Insights. Слушайте, да прямо сейчас вбейте туда свой сайт нажмите кнопку «Analize».
Окей, а теперь — о чём этот пост?
Вполне возможно, что в результатах проверки вашего сайта есть пункт «Eliminate render-blocking JavaScript and CSS in above-the-fold content».
Я заметил, что этот пункт один из самых трудноразрешимых (трудоёмких) и практически на всех сайтах, даже на очень быстрых, он присутствует.
Как его исправить в теории:
Как же обстоит дело на практике, и в данном конкретном случае — для сайтов на 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 вашего сайта.
add_action('wp_enqueue_scripts', 'true_peremeshhaem_jquery_v_futer'); function true_peremeshhaem_jquery_v_futer() { // снимаем стандартную регистрацию jQuery wp_deregister_script('jquery'); // регистрируем для подключения в футере, описание параметров - в документации функции (ссылка чуть выше) wp_register_script('jquery', includes_url('/js/jquery/jquery.js'), false, null, true); // подключаем wp_enqueue_script('jquery'); }
Хочу обратить ваше внимание на то, что это автоматизированное решение, и хотя оно работает практически в 100% случаев, бывает такое, что некоторые скрипты не хотят переноситься в футер сайта. Тогда уже потребуется более внимательный к каждому вашему файлу JavaScript.
На этом наша работа с JS заканчивается, конечно прирост в скорости даст ещё и объединение скриптов (то есть снимаете их все с регистрации и потом просто подключаете свою объединенную версию) — но Google сейчас это уже не требует.
2. Объединение CSS в WordPress
Если объединение всех JavaScript в один файл — не всегда хорошая идея, то CSS-ки я бы рекомендовал объединять по возможности всегда.
Помните скриншот в самом начале статьи (10 blocking CSS resources)? Откуда берется такое количество файлов стилей, ведь разработчик темы наверное понимал, что делает?
Ответ — из плагинов.
Например плагин «Contact Form 7» подключает свою собственную таблицу стилей, и хотя сама по себе она невелика, то лучше всё же избежать лишних HTTP-запросов.
Давайте пошагово разберем как.
add_action( 'wp_print_styles', 'true_otkljuchaem_stili_contact_form', 100 ); // по идее вы можете использовать и хук wp_enqueue_scripts, хотя конкретно его я не тестировал function true_otkljuchaem_stili_contact_form() { wp_deregister_style( 'contact-form-7' ); // в параметрах - ID подключаемого файла }
Также иногда при помощи условных тегов файлы плагинов (как CSS, так и JS) отключают только с тех страниц, на которых они не используется.
Ок, с «Contact Form 7» разобрались, а как узнать ID файлов CSS других плагинов?
Да легко, открываем исходный код страницы и видим там подобную картину:
Также есть плагин, который позволит выполнить объединение CSS и JavaScript автоматически — JS & CSS Script Optimizer.
Если у вас остались вопросы, либо я забыл упомянуть о чем-либо в этой статье, пожалуйста, оставьте свой комментарий.
(Пока оценок нет)
Загрузка...