Оптимизация JS и CSS | Корректная загрузка ресурсов сайта

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

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

На скриншоте перечень мер оптимизации по результатам теста LightHouse. 70% - касаются js и css.

Несмотря на то, что наиболее сильное влияние загрузка 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 для асинхронной загрузки:

<!DOCTYPE html> <html> <head> <link href="style.css" rel="stylesheet"> </head> <body> <div><img src="awesome-photo.jpg"></div> <script src="app.js" async></script> </body> </html>

Например, jQuery часто не нужно загружать сразу. Однако, на большинстве сайтов вы увидите, что jQuery стоит в <head> первым js ресурсом. Убрать запрос к jQuery из <head> и вызов его в <body> по необходимости будет правильным решением.

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

0
52 комментария
Написать комментарий...
Уоррен Баффет

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

Ответить
Развернуть ветку
Игорь Соколовский

Статья ради статьи, согласен

Ответить
Развернуть ветку
1 комментарий
Александр Поспелов
Автор

"Про работу со шрифтами" - будет отдельная статья.

Ответить
Развернуть ветку
1 комментарий
Виктор Петров

Ну как бы AJAX тот же Яндекс как не понимал, так и не понимает. Да и гуглобот со скрипом до сих пор. 

Ответить
Развернуть ветку
Алексей из LOADING.express

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

Ответить
Развернуть ветку
2 комментария
Валентин Федяков

На мой взгляд - это очень поверхностная статья. Например, вопрос подключения скриптов на сайт. Если у нас легаси ресурс и ранее вообще не использовались атрибуты асинхронной загрузки, то самое верное решение - 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-специалист?
Я имею в виду - отличная тема для статьи.

Ответить
Развернуть ветку
4 комментария
Алексей Медведев

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

Во вторых, каким боком здесь seoшник? Который может только дать рекомендации по оптимизации сайта!! На фиг ему знать как это делать? Какой, бля, seoшник полезет править dom-climata.ru, который на bitrix? Кто его туда пустит то?

В третьих, эта статья, скомканый пересказ материалов web.dev, она совсем не для этого блога! Не вешайте плиз на seoшников управление разработчиками, ибо они зашлют такого советчика ну ооочень далеко. 

Обращаясь к автору: попробуйте это опубликовать на habr! Думаю даже не пропустят.))) 

Ответить
Развернуть ветку
Vasiliy Gorin

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

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

Ответить
Развернуть ветку
Алексей из LOADING.express

Да, про скорость автор статьи мало знает, если такие советы дает. Будьте осторожны с такими оптимизаторами.

Ответить
Развернуть ветку
Nikita Spivak

Добавлю ко всему вышесказанному, что про внешние ресурсы тоже тема не раскрыта.

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

Например качаем себе метрику. В самом файле watch.js подключаются дополнительные файлы.

Получается нужно их тоже выкачивать? Тогда в коде основного файла нужно менять пути к скриптам, что противоречит автоматическому обновлению файлов через Cron.

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

Возможно у коллег есть решения?
Спасибо

Ответить
Развернуть ветку
Алексей из LOADING.express

В одном из эфиров раскрыли эту тему на 100% и дали даже скрипт для обертывания скриптов аналитики. Выкачивать не надо. Надо просто отложить в потоке на 100-300 миллисекунд и будет всё хорошо.
Смотрите

Ответить
Развернуть ветку
21 комментарий
Sly Death

Я не могу понять, сколько ещё надо мегабит скорости, чтобы мы забыли об оптимизации? Не в целом, а вот в такой частности, когда надо усираться ради лайтхауса, который считает, что сайт установки окон в Мухосранске должен быстро грузиться на скорости 2G в стране третьего мира на мобильнике 2003 года? Такой всё это бред. Давно ли вы открывали сайт 4лапы? Типичное тормозное фуфло на битриксе, однако свою роль выполняет. 🤦‍♂️

Ответить
Развернуть ветку
Dmitry Ulanov

Интересный метод. Спасибо) 

Ответить
Развернуть ветку
Vladimir Batenev

вы каким инструментарием пользуетесь для оценки скорости своего сайта? 

Ответить
Развернуть ветку
Уоррен Баффет

Омг. ) 9 секунд на что? )
Вот вам инструмент - https://www.webpagetest.org/
Если ваш сайт набирает Speed Index при тех или иных настройках более 1000, значит он тормозит и надо что-то делать.

Ответить
Развернуть ветку
5 комментариев
Vladimir Batenev

Сообщение удалено

Ответить
Развернуть ветку
Александр Романов

Слишком умная статья для vc.ru. Про это лучше писать на хабре.

Ответить
Развернуть ветку
49 комментариев
Раскрывать всегда