Начало ведения блога всегда сопровождается множеством ожиданий и надежд. Вы создаёте контент, размещаете его на сайте и ждёте, что поисковые системы начнут индексировать ваши страницы, приводя новых читателей. Однако реальность часто оказывается более сложной. Когда я впервые запустил свой блог, я рассчитывал, что Google быстро включит мои публикации в поиск, но спустя некоторое время выяснилось, что большинство страниц остаются проиндексированными, но не отображаются в результатах поиска. Тег "Crawled - currently not indexed" стал неприятным сюрпризом.
Это подтолкнуло меня к глубинному изучению причин такой ситуации. Среди основных факторов, которые влияют на индексирование сайта, выделяются содержание, количество внешних ссылок и производительность сайта. Конечно, контент всегда можно улучшать, а продвижение через сообщества и соцсети требует времени и усилий. Но производительность — аспект, который можно и нужно решать техническими средствами. Для анализа скоростных характеристик сайта я обратился к сервису Google PageSpeed Insights.
Результат был далеко не утешительным: плохой балл 43 из 100. Это явно сигнализировало о проблемах, которые мешают пользователям и поисковым роботам комфортно взаимодействовать с сайтом. Самыми большими проблемами оказалась загрузка шрифтов и мультимедийного контента, а также неоптимизированные изображения. Загрузка шрифтов с Google Fonts с помощью стандартного кода внедрения создавала задержки и блокировала рендеринг страниц. Чтобы исправить ситуацию, я решил отказаться от использования CDN Google Fonts и самостоятельно разместить нужные шрифты на своем сервере.
Это оказалось не таким сложным: достаточно было скачать CSS и файлы шрифтов формата woff2, настроить стили на использование локальных ресурсов и отфильтровать неиспользуемые шрифты, чтобы снизить общий вес. Для автоматизации этой задачи можно использовать сторонний инструмент google-webfonts-helper, который облегчает выгрузку и настройку шрифтов для локального хостинга. Следующая проблема связана с встраиванием видео с YouTube. Используемый по умолчанию код через кнопку «Поделиться» загружал полный iframe, что значительно замедляло страницу еще до взаимодействия пользователя. Поисковые системы даже рекомендуют использовать облегчённые встраивания через специализированные библиотеки, такие как lite-youtube, которые подгружают основной видеоплеер только при нажатии, а предварительно показывают лишь миниатюру.
Я выбрал библиотеку justinribeiro/lite-youtube и даже внёс небольшое исправление, чтобы гарантировать загрузку миниатюр для плейлистов, что не поддерживалось из коробки. Наибольшую нагрузку на производительность, однако, создавали изображения — их размер и отсутствие адаптивности приводили к долгой загрузке и плохому пользовательскому опыту. Все изображения были односнимковыми и высокого разрешения, без использования современных форматов или вариантов для различных экранов. Для решения вопроса необходимо было автоматически создавать несколько версий каждого изображения с разными размерами и форматами, такими как WebP и AVIF, а также задействовать ленивую загрузку (lazy loading). Современные сайты применяют srcset и picture для адаптивной подачи медиа.
Попытка использовать готовые решения для Jekyll, например jekyll-assets, не вдохновила: библиотека давно не обновлялась, была громоздкой и интегрировалась со старой сущностью Sprockets — мощным, но устаревшим способом работы с ассетами из Ruby on Rails. Современные подходы пошли по пути минималистичных инструментов, таких как Propshaft, который оставляет обработку CSS и JavaScript на сторонних сборщиках вроде esbuild, при этом отвечает за добавление кеш-френдли хешей и обновление путей в стилях. В Jekyll отсутствовало подобное решение, что подтолкнуло меня написать собственный плагин jekyll-skyhook. Этот инструмент позволяет легко выполнять трансформации изображений: изменение размера, преобразования формата в WebP и AVIF, генерацию srcset для адаптивных загрузок, автоматическую подмену кешируемых URL с добавлением хешей для контроля кеша, а также ускоряет процесс разработки при помощи слежения за изменениями файлов и манифеста для кэширования уже обработанных ресурсов. Ликвид-теги {% asset %}, {% image_transform %} и {% srcset %} дают гибкость в управлении активами и изображениями во время генерации сайта.
Плагин совместим с image_processing gem, что предоставляет мощь обработки изображений на уровне сайта. Помимо оптимизации изображений, я пересмотрел структуру хранения исходного кода CSS и JavaScript. Они находятся в каталоге src/, а конечная обработка происходит с помощью современных инструментов, таких как Tailwind CSS и esbuild, которые выводят минифицированный и собранный код в папку assets/. Это даёт возможность использовать знакомые и удобные npm-скрипты для сборки и наблюдения за изменениями, что важно для быстрого цикла разработки и деплоя. Например, Tailwind CSS генерирует стили с учётом текущих настроек, а esbuild отвечает за бандлинг и минификацию JS.
Референсы в HTML создаются с помощью тега {% asset %}, что позволяет автоматически подставлять пути с хешами и облегчать кеширование браузера. Для локальной разработки я использую утилиту foreman с Procfile, которая одновременно запускает watch-скрипты для CSS и JS и сервер Jekyll с параметром -D для показа черновиков. Такой подход ускоряет итерацию работы над сайтом и позволяет быстро видеть результат изменения кода. В фазе продакшена я собираю CSS и JS, затем выполняю jekyll build с подробным выводом, затем разворачиваю сайт с помощью Wrangler Pages — современной платформы для развертывания статических сайтов на Cloudflare. Для интеграции оптимизированных изображений я написал специальный include responsive-image.
html, который генерирует тег picture с поддержкой AVIF, WebP и оригинального формата, а также создает набор изображений с различными ширинами и атрибутами для адаптивного отображения. Теги srcset и sizes определяют поведение загрузки и позволяют браузеру выбрать самый подходящий вариант в зависимости от размеров экрана и плотности пикселей. В итоговом виде весь этот комплекс изменений дал ощутимый прирост производительности. Балл PageSpeed вырос с провального 43 до впечатляющего 99 из 100 баллов. Это означает не просто комфортную работу для конечных пользователей, но и положительно сказывается на позициях сайта в поисковой выдаче и скорости индексации.
