В процессе своей работы мы обучаем клиентов тому, что знаем сами, но и сами учимся у клиентов.
Вот пример из практики, который заставил меня вникнуть в тему ускорения загрузки сайтов с помощью оптимизации скриптов.
📝 Ситуация
Сверстали мы клиенту шаблон сайта для WordPress. Сдали проект, все хорошо, и клиент вернулся к нам снова с новым похожим проектом, тоже только верстка, которую нужно натянуть на WordPress.
И спрашивает: “Будут ли такие же высокие показатели в Google PageSpeed, как и у прошлого проекта?”.
А суть в том, что мы, когда собираем сайты, не смотрим на Google PageSpeed. Потому что немало есть уже готовых исследований от международных SEO-компаний, которые говорят, что скорость загрузки сайта не критична для того, чтобы занимать высокие позиции в выдаче. Достаточно, чтобы сайт загрузился быстрее, чем за 3 секунды.
Поэтому, когда мы делаем технический аудит при сдаче сайта, программа проверяет: быстрее трёх секунд или не быстрее трёх секунд. Собственно, всё на этом.
📊 Что получилось
Оказалось, что наша верстка выдала больше 90 баллов в Google PageSpeed.
В принципе, это понятно, потому что никаких плагинов для визуализации и украшения не было. Просто лёгкая верстка, которая естественно быстро грузится.
Но первом проекте вопрос вообще не стоял, а в новом проекте — был задан. Поэтому я стал проверять и другие наши сайты, в том числе наш собственный.
😅 Неожиданное открытие
Оказалось, что у нас не то, что нет 90, у нас 2 для мобильной версии и 7 для десктопной. Ну, думаю, ок, что и требовалось доказать. Ведь в Гугле мы на 1-2 позициях по всему пулу своих запросов.
И тут выясняется, что мы получили откат по позициям в Гугле на 10-20-30-е места. Как так вышло? А у нас основной упор на Яндекс, поэтому позиции проверяются по нему ежедневно, а в Гугле — раз в несколько месяцев.
И это заставило меня начать изучать вопрос ускорения оптимизации. Не факт, что после ускорения позиции вернутся, но пока это первая очевидная причина.
✅ Итоги
- Ниже в посте — рейтинг по скорости загрузки разных способов ускорения. Если никогда этим вопросом не озадачивались, то это готовая выжимка.
- Сейчас у нас разрабатывается плагин, который будет ускорять сайты на WordPress с применением всех этих методов.
🔧 Зачем свой плагин
Есть уже немало готовых решений по ускорению, но проблема в том, что после изучения десятка подобных плагинов, выводы у меня такие:
- они все работают кусочками,
- одни дают одни опции, другие — другие,
- часть опций платная,
- части опций вообще нет.
И чтобы всё это собрать в кучу, проще сделать своё решение. Этим сейчас и занимаюсь, и надеюсь, что через 1-2 недели уже покажу результаты.
🏆 Рейтинг по скорости
Async + Defer – лучший вариант для большинства скриптов (jQuery, плагины, аналитика). Async – быстрый старт, подходит для аналитики, счетчиков, виджетов. Footer – безопасно и стабильно, можно использовать для большинства скриптов. Defer – надежный, но самый «медленный», применим для критичных скриптов.
🎛️ Подробные описания
1️⃣ Перенос в Footer
✅ Преимущества:
• Быстрее отображается HTML
• Улучшается FCP (контент появляется раньше)
• Минимум блокировки рендеринга
❌ Недостатки:
• Скрипты стартуют только после загрузки DOM
• Возможны проблемы с кнопками/формами до их инициализации
2️⃣ Async (асинхронная загрузка)
✅ Преимущества:
• Не блокирует парсинг HTML
• Выполняется сразу после загрузки
• Улучшается LCP (основной контент быстрее)
❌ Недостатки:
• Порядок выполнения не гарантирован
• Может отработать до готовности DOM
3️⃣ Defer (отложенная загрузка)
✅ Преимущества:
• Не блокирует парсинг HTML
• Выполняется после готовности DOM
• Сохраняется порядок выполнения
❌ Недостатки:
• Медленнее, чем Async
• Скрипты стартуют только после полной загрузки
4️⃣ Async + Defer (комбинированно)
✅ Преимущества:
• Максимальная производительность
• Баланс скорости и безопасности
❌ Недостатки:
• Требует правильного выбора скриптов
• Возможны конфликты зависимостей
