Оптимизация JS и CSS | Корректная загрузка ресурсов сайта
Привет! Здесь постараюсь рассказать об основных приёмах оптимизации загрузки ресурсов, которые нужно знать seo-специалисту в целях ускорения сайта. В статье я дам несколько примеров, с которыми наиболее часто сталкиваются оптимизаторы в своей работе.
Итак, воспользовавшись инструментами тестирования скорости загрузки оптимизатор определяет перечень рекомендаций. Одним из основных пунктов, наряду с оптимизацией изображений, является пункт, связанный с загрузкой ресурсов, отвечающих за отображение контента на сайте.
- Используйте правильную очередность загрузки ресурсов.
- Подключайте 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>
Располагайте скрипты в <body> и указывайте атрибуты async или defer для асинхронной загрузки:
Например, jQuery часто не нужно загружать сразу. Однако, на большинстве сайтов вы увидите, что jQuery стоит в <head> первым js ресурсом. Убрать запрос к jQuery из <head> и вызов его в <body> по необходимости будет правильным решением.
Очень поверхностная статья. Например, откладывая исполнение скриптов аналитики вы теряете часть данных. Многое можно не грузить вообще, до совершения пользователем какого-то действия. Например, скролинга. Или скрипт поиска по сайту можно не грузить, пока поле поиска не в фокусе. Про работу со шрифтами ничего не сказали, про CLS... В общем так себе статья...
Статья ради статьи, согласен
"Про работу со шрифтами" - будет отдельная статья.
Ну как бы AJAX тот же Яндекс как не понимал, так и не понимает. Да и гуглобот со скрипом до сих пор.
откладывать исполнение аналитики можно и нужно, это нормально работает, но делать это надо зная нюансы или просто иметь опыт.
На мой взгляд - это очень поверхностная статья. Например, вопрос подключения скриптов на сайт. Если у нас легаси ресурс и ранее вообще не использовались атрибуты асинхронной загрузки, то самое верное решение - 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-специалист?
Я имею в виду - отличная тема для статьи.
Очередной раз удивляюсь.....
Во первых, скорость загрузки сайта на ранжирование сайта (в контексте seo) имеет далеко не первоочередное значение. Как не пытайтесь обыгрывать эту тему - полная херня!!
Во вторых, каким боком здесь seoшник? Который может только дать рекомендации по оптимизации сайта!! На фиг ему знать как это делать? Какой, бля, seoшник полезет править dom-climata.ru, который на bitrix? Кто его туда пустит то?
В третьих, эта статья, скомканый пересказ материалов web.dev, она совсем не для этого блога! Не вешайте плиз на seoшников управление разработчиками, ибо они зашлют такого советчика ну ооочень далеко.
Обращаясь к автору: попробуйте это опубликовать на habr! Думаю даже не пропустят.)))
Про перенос вроде jQuery из head в body - очень плохой совет из далёкого прошлого. В современном вебе для скриптов, которые в любом случае понадобятся на странице, но будут нужны только после её загрузки, нужно просто добавить атрибут defer, но переносить их ниже не нужно, это только навредит общей скорости загрузки страницы.
Автору следует подтянуть свой уровень знаний, прежде чем писать статьи. Сейчас это выглядит как надёрганные по верхам устаревшие советы, которые при неправильном понимании (как у автора) могут даже навредить.
Да, про скорость автор статьи мало знает, если такие советы дает. Будьте осторожны с такими оптимизаторами.
Добавлю ко всему вышесказанному, что про внешние ресурсы тоже тема не раскрыта.
Даже если изогнуться и выкачать ту же Яндекс Метрику или Google Analytics, решить вопрос с их обновлением через крон, то остается проблема подключения внешних скриптов, подключаемых в основном файле.
Например качаем себе метрику. В самом файле watch.js подключаются дополнительные файлы.
Получается нужно их тоже выкачивать? Тогда в коде основного файла нужно менять пути к скриптам, что противоречит автоматическому обновлению файлов через Cron.
Если исключить автоматическое обновление - то нужно следить за статистикой, чтобы не пропустить момент когда что-то изменится в коде и отслеживание прекратит работу.
Возможно у коллег есть решения?
Спасибо
В одном из эфиров раскрыли эту тему на 100% и дали даже скрипт для обертывания скриптов аналитики. Выкачивать не надо. Надо просто отложить в потоке на 100-300 миллисекунд и будет всё хорошо.
Смотрите
Я не могу понять, сколько ещё надо мегабит скорости, чтобы мы забыли об оптимизации? Не в целом, а вот в такой частности, когда надо усираться ради лайтхауса, который считает, что сайт установки окон в Мухосранске должен быстро грузиться на скорости 2G в стране третьего мира на мобильнике 2003 года? Такой всё это бред. Давно ли вы открывали сайт 4лапы? Типичное тормозное фуфло на битриксе, однако свою роль выполняет. 🤦♂️
Интересный метод. Спасибо)
вы каким инструментарием пользуетесь для оценки скорости своего сайта?
Омг. ) 9 секунд на что? )
Вот вам инструмент - https://www.webpagetest.org/
Если ваш сайт набирает Speed Index при тех или иных настройках более 1000, значит он тормозит и надо что-то делать.
Сообщение удалено
Слишком умная статья для vc.ru. Про это лучше писать на хабре.