Услуга

Ускорение сайта

Ускоряю сайты: уменьшаю время загрузки, оптимизирую картинки, чищу неиспользуемый CSS и JS, настраиваю кеш и CDN. Замеряю PageSpeed до и после, показываю конкретные цифры в отчёте.

  • Аудит текущей скорости
  • Картинки
  • CSS и JS
Обсудить задачу Стоимость от 8 000 ₽
Изометрическая иллюстрация: спидометр у компьютера переходит в зелёную зону, рядом картинки сжимаются в WebP, графики с метриками улучшаются
Что входит

Из чего складывается услуга

  • Аудит текущей скорости

    Замер по PageSpeed Insights, Core Web Vitals (LCP, INP, CLS), WebPageTest. На каких страницах хуже всего, где основная просадка: серверный рендер, картинки, скрипты, шрифты. Без этого замера ускорение это пальцем в небо.

  • Картинки

    Перевожу в WebP, на критичных местах в AVIF. Настраиваю lazy-loading, явные width/height (закрывает CLS), `srcset` для разных экранов. На большом каталоге вес страниц падает в 3-5 раз.

  • CSS и JS

    Критичный CSS инлайню в `<head>`, остальное defer. JS, который не нужен на первом экране, переношу в `defer` или `async`. Неиспользуемый код (например, jQuery, который остался от старого плагина) удаляю.

  • Кеш и CDN

    Серверный кеш (Redis или встроенный для CMS), браузерный (HTTP-заголовки), CDN для статики. Из CDN под российский трафик хорошо работают BunnyCDN и Yandex Cloud. HTTP/3 включаю, где хостер позволяет.

  • Шрифты

    Self-hosting вместо Google Fonts (приватность плюс скорость). `font-display: swap`, `preload` ключевых начертаний. Подключаю только нужные веса и наборы символов (для русских сайтов это `cyrillic` плюс `cyrillic-ext`, без вьетнамского).

  • Замер после

    Те же тесты, что до. Цифры в отчёте: LCP было 4.2, стало 1.6. CLS было 0.18, стало 0.04. PageSpeed mobile был 28, стал 87. Если по каким-то метрикам не дотянули до целевых, объясняю причину и предлагаю что делать дальше.

Как работаю

Поэтапно — от первого аудита до постоянной работы

01

Замер

Снимаю текущие метрики на 5-7 ключевых страницах: главная, каталог, карточка товара, корзина, контакты. Десктоп и мобильный отдельно. На выходе таблица с цифрами и список найденных проблем по приоритету.

02

План работ

Раскладываю задачи на критичные (сильно влияют на LCP) и плановые (мелкие оптимизации). Согласуем, что делаем сейчас, что в следующий заход. На этом этапе видно ожидаемое улучшение в цифрах.

03

Внедрение

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

04

Финальный замер

На проде через сутки после внедрения (чтобы CDN-кеши прогрелись и Real User Monitoring собрал данные). Отдаю отчёт с до/после, ссылками на тесты и рекомендациями, что мониторить дальше.

Зачем вообще ускоряться

Скорость сайта это не модная метрика. У неё есть три практических следствия для бизнеса малого размера.

Первое: позиции в поиске. Google ранжирует по Core Web Vitals (LCP, INP, CLS). Yandex напрямую не ранжирует, но завязывает поведенческие факторы на скорость, и медленные сайты теряют места независимо от ссылок и контента. Разница между LCP 1.5 секунды и 4 секунды в высококонкурентной нише это разница между топ-3 и топ-30.

Второе: процент завершённых заявок. Замеры Google: каждая дополнительная секунда загрузки уводит 7-12 процентов посетителей. На сайте с 10 тысячами визитов в месяц и 2 процентами конверсии это 20-30 потерянных лидов в месяц. На длинной дистанции скорость окупает себя за пару месяцев работы.

Третье: индексация. Большие медленные сайты Google и Yandex обходят реже, новые страницы индексируются дольше. Если у вас интернет-магазин, в котором товары появляются ежедневно, это критично: новый товар попадает в выдачу через 2 дня, а не через 2 недели.

Что обычно тормозит

Реальные причины из аудита 40 проектов за последний год, по убыванию частоты:

  1. Неоптимизированные картинки. Главная страница весит 8 МБ, потому что hero-фото загружается оригиналом 4000×3000. Чинится за час: WebP плюс resize плюс lazy-loading.
  2. JS-плагины, которые не нужны на текущей странице. На странице ‘Контакты’ зачем-то грузится корзина, swiper, карта Яндекса (если её нет на странице) и ещё 5 трекеров. Чинится: разносим скрипты по страницам, defer для некритичных.
  3. Хостинг, который тормозит на TTFB. Shared-хостинг, перегруженный соседями, отдаёт первый байт за 800-1500 мс. Это потолок, оптимизацией не починить, нужен переезд на хостинг получше.
  4. Тяжёлые темы и сборки. Мега-темы для WordPress (Avada, Divi, Bridge) тащат 200-500 КБ только своего кода. Если уже на ней живём, оптимизирую насколько возможно. Если только выбираете, рекомендую лёгкие альтернативы.
  5. Шрифты с Google Fonts CDN. Тащат 6-12 запросов на сторонние домены, увеличивают LCP. Self-host решает за 30 минут, плюс это ещё и плюс к 152-ФЗ.

Что НЕ ускоряет (популярные мифы)

Несколько вещей, которые часто продают как ускорение, но реальную пользу дают мало или дают не там, где обещают:

  • Платный плагин-кеш на WordPress в 70 процентов случаев не быстрее бесплатного W3 Total Cache или встроенного. Платите 100 долларов за тот же результат, что у бесплатного.
  • ‘Ускорение через мощный VPS’. Если у вас shared с TTFB 800 мс, переезд на VPS уберёт TTFB до 200 мс, и это полезно. Но если у вас уже хороший shared с TTFB 200 мс, переезд на VPS почти ничего не даст: основная просадка скорости не там.
  • AMP-страницы для мобильных. Google формально снизил вес AMP в ранжировании ещё в 2021. Сегодня AMP это легаси-формат, который добавляет работы по поддержке без выгоды. Не делаю, не предлагаю.

Когда я могу не подойти

Если у вас высоконагруженный SaaS с уникальным API и серверным рендерингом на Node.js, для глубокой оптимизации нужен профильный backend-разработчик, не я. Я закрываю фронтенд-сторону: HTML, CSS, JS, картинки, шрифты, кеш. Серверную оптимизацию (запросы к БД, индексы, балансировка нагрузки) делаю на простом уровне типовых CMS, для нестандартного бэкенда нужен другой человек.

В таких случаях честно говорю на этапе аудита: вот что я могу закрыть, вот что нужно отдать другому специалисту. Аудит платится отдельно, дальше решаете сами.

Смежные услуги: Технический аудит, Поддержка сайта, Перенос сайта.

  1. Сколько баллов PageSpeed станет после оптимизации?

    Зависит от стартового состояния и стека. Типовые улучшения: WordPress на shared со стартом 25-35 баллов мобильно поднимаю до 75-85. Bitrix со стартом 15-30 поднимаю до 60-75 (Bitrix труднее WordPress, у него тяжёлое ядро). Tilda со стартом 50-65 до 85-95. Сайты на современных фреймворках (Astro, Next.js) обычно сразу 90+, и работа сводится к мелким правкам.

  2. Гарантии конкретных цифр?

    Гарантирую улучшение по каждой из метрик Core Web Vitals (LCP, INP, CLS). Если после моей работы LCP не сократился, возвращаю стоимость работ. Конкретный итоговый балл PageSpeed не гарантирую, потому что он зависит от вещей вне моего контроля: новые требования Google, изменения в учёте метрик, реклама Яндекса на сайте. Целевые значения согласовываем заранее.

  3. Подойдёт для WordPress / Bitrix / Tilda?

    Для WordPress: да, базовая работа. Кеш, картинки, плагины, шрифты, неиспользуемый JS. Обычно балл вырастает в 2-3 раза. Для Bitrix: да, но дороже, потому что ядро Bitrix тяжёлое и часть оптимизаций требует доработки шаблона. Для Tilda: ограниченно. Tilda сама генерит оптимизированный код, добавить можно немного: lazy-loading медиа, отключение ненужных блоков, кастомный код для Yandex Pixel и Метрики. Радикально ускорить Tilda нельзя, она и так быстрая.

  4. Сколько по времени?

    От 1 рабочего дня (для простого сайта на коробочной CMS) до 2 рабочих недель (для крупного интернет-магазина с нестандартным шаблоном). Среднее: 4-6 рабочих дней с момента старта.

  5. А мобильная скорость?

    Это и есть основное. Google и Yandex давно ранжируют по мобильной версии. PageSpeed mobile обычно ниже desktop, потому что эмулируется медленный 4G и средний смартфон. Я работаю с обеими версиями, но приоритет mobile, потому что у среднего сайта малого бизнеса 60-80 процентов трафика приходится на телефоны.

Отзывы

Что говорят клиенты

  • Перевели все картинки в WebP, прикрутили нормальный lazy-load, причесали порядок загрузки шрифтов. Lighthouse Performance на мобильных вырос с 47 до 95, статьи стали открываться почти мгновенно. Время на странице по Метрике подросло на 22 секунды в среднем.

    Юлия С. главный редактор онлайн-журнала, Слово и Стиль
  • Bitrix Composite Cache настроили нормально, плюс убрали лишние хиты к БД на главной и в каталоге. Нагрузка на сервер по CPU упала на 60% в часы пик, хостер перестал слать письма про превышение лимитов. Заодно выдержали Чёрную пятницу без падений, чего раньше не было.

    Виктор Б. интернет-магазин кормов для животных
  • INP на странице тарифов был 420 мс, кнопки реагировали с заметной задержкой. Разнесли тяжёлый JS на чанки, отложили несрочные обработчики, выкинули устаревшую библиотеку анимаций. INP стал 140 мс, метрика в Search Console позеленела через 28 дней.

    Алексей Н. продакт-менеджер SaaS-проекта, Таскфло
  • Замеряли конверсию в заявку до и после ускорения сайта, рост 18% по данным Яндекс Метрики за следующий месяц. Параллельно средняя глубина просмотра выросла с 2.1 до 2.8 страниц. Работы заняли около трёх недель, без переделки дизайна.

    Наталья Г. директор по маркетингу в производстве, ПромЛит
  • Прошли Core Web Vitals в Google Search Console, получили оценку "хорошо" по всем трём метрикам на 92% URL. До этого болталось 34% URL в красной зоне больше полугода. Позиции в Google по коммерческим запросам подросли в среднем на 6 пунктов за месяц.

    Сергей П. SEO-специалист в небольшой студии
  • Bitrix-сайт грузился 8 секунд на главной, менеджеры жаловались, что клиенты не дожидаются. После настройки композитного кеша и чистки неиспользуемых модулей время загрузки упало до 1.5 секунды. Заявок с сайта стало больше примерно на четверть, точнее посчитаем по итогам квартала.

    Дмитрий В. B2B-компания по поставкам оборудования, ТехСнаб Партнёр
  • У клиентского лендинга CLS был 0.32, баннер с акцией прыгал, аналитика догружалась после первого экрана. После фикса резерва места под баннер и асинхронной загрузки скриптов CLS опустился до 0.02. Search Console через две недели поставил Core Web Vitals в зелёную зону.

    Игорь Ш. маркетолог digital-агентства
  • LCP на главной был 5.2 секунды, после оптимизации картинок и переноса шрифтов на self-hosted упал до 1.4 секунды. Карточки товара тоже подтянулись, теперь укладываются в 1.8с на 4G. Заметили по Метрике, что отказы с мобильных снизились с 41% до 29%.

    Андрей К. интернет-магазин спорттоваров
  • Подключили CDN для статики, мобильный TTFB снизился с 780 мс до 340 мс на регионах за Уралом. Картинки и CSS теперь летят с ближайшей точки, а не из московского ДЦ. Читатели из Сибири перестали жаловаться, что страницы открываются дольше пяти секунд.

    Михаил Т. новостной блог
  • PageSpeed на мобильных был 28, через две недели работы стал 91. Через месяц подросли позиции в Google и Яндексе по среднечастотным запросам, трафик из поиска +22%. Делали оптимизацию картинок, кеш и чистку лишних скриптов.

    Татьяна Р. интернет-магазин косметики
  • Вес главной страницы был 3.4 МБ, в основном из-за неоптимизированных баннеров и слайдера. Снизили до 850 КБ за счёт WebP, lazy-load и удаления старого карусельного скрипта. Мобильная версия стала открываться за 2 секунды вместо 6, конверсия в корзину подросла.

    Елена М. интернет-магазин обуви
  • Сайт на WordPress был обвешан 27 плагинами, половина из которых не использовалась годами. Вычистили 14 штук, заменили тяжёлый конструктор на нативный блочный редактор. Админка перестала тормозить, фронт стал открываться за 1.7 секунды вместо 4.5.

    Ольга Д. интернет-магазин инструмента

Передайте техническую часть в надёжные руки.

Слежу за хостингом, бэкапами и обновлениями. Когда что-то пойдёт не так — звоните мне, не своему программисту, не в спортзал и не маме.

Заявка

Обсудим задачу

Напишите имя и телефон, выберите удобный канал. Перезвоню или напишу в течение часа в рабочее время.

Куда удобнее ответить?