Оптимизация JS и CSS | Корректная загрузка ресурсов сайта
Привет! Здесь постараюсь рассказать об основных приёмах оптимизации загрузки ресурсов, которые нужно знать seo-специалисту в целях ускорения сайта. В статье я дам несколько примеров, с которыми наиболее часто сталкиваются оптимизаторы в своей работе.
Итак, воспользовавшись инструментами тестирования скорости загрузки оптимизатор определяет перечень рекомендаций. Одним из основных пунктов, наряду с оптимизацией изображений, является пункт, связанный с загрузкой ресурсов, отвечающих за отображение контента на сайте.
Несмотря на то, что наиболее сильное влияние загрузка js и css оказывает на показатели Time to Interactive и Total Blocking Time. Для целей SEO, в первую очередь, важна отрисовка первого экрана. Чтобы не останавливаться на этом, ниже даю небольшой чек-лист для оптимизации FCP:
- Используйте правильную очередность загрузки ресурсов.
- Подключайте js и css по типам страниц, чтобы время загрузки не уходило на неиспользуемые файлы.
- Откажитесь от запросов @import url("style.css").
- Стили, влияющие на FCP расположите inline внутри html-странички.
- Минимизируйте количество js кода для отрисовки первого экрана.
Рекомендации к JS и CSS по LightHouse
- Устраните ресурсы, блокирующие основной поток
Такие ресурсы - это <script> (без defer и async) и стили <link rel="stylesheet">, подключаемые в <head>. Как правило, наибольшую нагрузку вызывают скрипты, подключенные через внешний ресурс, а также js сервисов веб-аналитики.
Отсюда вытекают 2 рекомендации
1. Все ресурсы нужно хранить локально. Внешний запрос может осуществляться слишком долго.
<link href="/templatev1.css" type="text/css" rel="stylesheet">
Когда вы скопируете код и сохраните его локально. У вас появятся возможности по дополнительной оптимизации. Вы сможете:
Сокращать файлы - удалять части кода, невостребованные для вашего сайта.
Минифицировать - сжимать файлы.
Комбинировать файлы - объединять несколько небольших файлов.
2. Всем ресурсам, не связанным с отображением элементов первого экрана, нужно обеспечивать асинхронную загрузку. <script async="" src="/analytics.js"></script>
Подключение скрипта в <head> - это и есть блокировка загрузки страницы. Если вы посмотрите на свой сайт внимательно, то поймёте, что 90% всего js используется ниже первого экрана. А если это не так, то следует к этому прийти.
Располагайте скрипты в <body> и указывайте атрибуты async или defer для асинхронной загрузки:
Например, jQuery часто не нужно загружать сразу. Однако, на большинстве сайтов вы увидите, что jQuery стоит в <head> первым js ресурсом. Убрать запрос к jQuery из <head> и вызов его в <body> по необходимости будет правильным решением.
Подводя итог, скажу, что свои усилия стоит сосредоточить на устранении блокировки загрузки, т.к. второстепенные меры оптимизации являются её составными частями.
На мой взгляд - это очень поверхностная статья. Например, вопрос подключения скриптов на сайт. Если у нас легаси ресурс и ранее вообще не использовались атрибуты асинхронной загрузки, то самое верное решение - defer, за счёт того, что он не блокирует отрисовка страницы и формирование dom при загрузке скриптов, а так же гарантирует порядок исполнения скроптов после события domcontentloaded, переносить скрипты из head не нужно. Использование же async в большенстве случаев вызывает race condition и самое главное, что если ресурс с качается быстрее, чем html распарсится, то он будет так же блокирующим ресурсом (банальный пример: пользователь вернулся на ваш сайт и ему из кеша идут ресурсы). Async вообще лучше использовать для различных метрик, с которыми не общается твой код, а они живут сами по себе. Использование critical css т.е. inline внесение css первого экрана в head в саму структуру html приводит к раздуванию самого html которому не всегда дают правила кеширования, т.е. вынуждая каждый раз загружать большой html. Плюс ко всему, такой подход частенько вынуждает переставать layout страницы и просаживал метрику смещения layout того же lighthouse. Моя практика использования cdn (системы распределенной поставки ресурсов) показала, что лучше с ней, чем без неё в большинстве случаев, а что бы минимизировать негативный эффект на TTFB за ресурсом, то делать prefech или preconnect в зависимости от ситуации.
Вы разработчик или SEO-специалист?
Я имею в виду - отличная тема для статьи.
Разработчик. Не уверен, что хорошая тема т.к. на том же хабре достаточно статей описывающий различные методики оптимизации перфоманс. Но я бы с удовольствием почитал про 2 штуки:
1) решенные кейсы. Типа берём сайт, проводим анализ различным туллингом со скриншотами и объяснением полученных данных, далее на основе результатов делаем заключение с указанием вещей, что и как поправить и после выполнения рекомендаций - сравнение на до и после.
2) доказать зависимость поисковой выдачи от результатов перфоманс гугла. Типа мой сайт просел на 5 баллов, что это для меня значит и как повлияет? А 20 баллов посадка? А если у меня 0 из 100 баллов, мой сайт пропадёт из выдачи (споллер, нет)? Т.е. зачем вообще для seo делать оптимизацию перфоманс (именно для seo, а не для пользователя)? Мой опыт показал, что она есть..... но слишком призрачна. В основном все диктуется - есть баллы и мы должны получить их много потому что где то кто то сказал, что это влияет на поисковую выдачу.
1) на примере кейса информация воспринимается интереснее. и описать его можно детально. согласен с критикой. у меня, материал обрисован в общих чертах.
2) для пользователя - значит для seo. это мой подход, который я не пропагандирую. конечная цель таких доработок - улучшение UX.