Ускорение сайта на WordPress: главная на телефоне с 12,7 до 2,2 секунды

Это кейс про наш собственный сайт, la-chatte.com. В конце августа 2026 года главная страница на телефоне грузилась так, что человек видел белый экран. Главная картинка появлялась через 12,7 секунды. За пять недель мы довели её до 2,2 секунды, вес страницы уменьшили в четыре раза, а сервер теперь отдаёт готовую страницу в сто с лишним раз быстрее. Ниже по шагам: что тормозило, что мы сделали, как проверили и что сознательно не стали трогать.

Почему мы пишем про себя. Сайт агентства работает как витрина: по нему клиент судит, умеем ли мы делать сайты. Если витрина грузится 12 секунд, разговор о доверии заканчивается, не начавшись. А ещё на своём сайте можно показать всё: настоящие цифры, ошибки по дороге, файлы настроек. Чужие сайты мы так подробно раскрыть не можем.

Кто клиент

Клиент здесь мы сами. La Chatte делает сайты, поддержку сайтов на WordPress и 1С-Битрикс и внедряет искусственный интеллект в бизнес. Сайт la-chatte.com работает на WordPress: это готовая система для сайтов, одна из самых популярных в мире. У нас своя тема оформления, 19 плагинов, сервер в России, в Москве.

Сервер небольшой: два ядра и 2 ГБ памяти. Это важно. Мы не решали задачу деньгами, то есть не переезжали на дорогой сервер. Всё сделано на том же железе.

В чём была задача

Медленный сайт теряет людей. Человек нажал на ссылку в поиске, увидел белый экран и вернулся назад. Яндекс это замечает: если люди уходят со страницы, он показывает её реже. Значит, скорость влияет и на продажи, и на место в поиске.

Задачу поставили так: сделать так, чтобы сайт быстро открывался на обычном телефоне через мобильный интернет. Именно на телефоне, а не на мощном компьютере в офисе. И при этом ничего не сломать: форма заявки, счётчик Яндекс Метрики и всё, что приносит клиентов, должно работать как раньше.

Что было в конце августа

28 августа мы сделали первый замер главной страницы. Мерили инструментом Lighthouse от Google. Он открывает страницу так, как её открыл бы средний телефон через мобильный интернет, и ставит оценку от 0 до 100.

• Оценка: 30 из 100. Это красная зона.
• Главная картинка первого экрана появлялась через 12,7 секунды. У Google хорошим считается результат до 2,5 секунды.
• Страница весила 3,5 МБ и делала 136 запросов к серверу.
• Телефон был занят почти 3 секунды и в это время не реагировал на нажатия.
• Сервер собирал каждую страницу заново, на это уходило 0,6–0,9 секунды ещё до того, как начиналась загрузка.

На живом телефоне это выглядело ещё хуже: белый экран, полоса загрузки застревает на трети. Человек не видел ни текста, ни картинок, ни кнопки «Оставить заявку».

Как мы мерили

Сразу договорились о правилах, иначе можно обмануть самих себя.

Один замер ничего не значит. Lighthouse шумит. Три прогона одной и той же страницы подряд дали нам 63, 89 и 89 баллов. В другой день соседние прогоны дали 70 и 90. Поэтому каждую правку мерили три раза и брали среднее по порядку значение, медиану. Для этого написали отдельный скрипт.

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

Перед каждой правкой снимали копию. Файлы, настройки, база данных. У каждого шага в нашем журнале записано, как вернуть всё назад за минуту.

Шаг 1. Шрифты: 384 КБ превратились в 66 КБ

Что видели. Сайт грузил три файла шрифта SF Pro общим весом 384 КБ. В каждом лежали тысячи знаков: греческий, вьетнамский, математические символы. Нам нужны только русские и латинские буквы, цифры и знак рубля. Слабый процессор телефона разбирал эти файлы целиком и в это время больше ничего не делал.

Что сделали. Перевели шрифты в современный сжатый формат и оставили в них только нужные знаки. Попросили браузер скачивать шрифты первыми, вместе со страницей, а не ждать, пока он сам их найдёт. И разрешили показывать текст сразу обычным шрифтом, а свой подставлять, когда он приедет. Раньше браузер прятал текст, пока не загрузится шрифт.

Результат. Шрифты на главной: 384 КБ стали 66 КБ. По всем восьми файлам шрифтов сайта: 726 КБ стали 196 КБ, минус 74%. Одна эта правка подняла оценку главной с 30 до 61. Время, когда телефон «завис» и не отвечает, сократилось с 2960 до 320–340 мс, почти в девять раз.

Попутно нашли архив шрифтов на 2 МБ, который лежал на сайте по прямой ссылке. Любой мог его скачать. Убрали.

Шаг 2. Картинки: те же картинки, в разы легче

Что видели. Картинки занимали 2,6 МБ из 3,5 МБ страницы. Одна картинка размером 720 на 500 точек весила 789 КБ. Плагин для сжатия картинок на сайте стоял и даже подготовил лёгкие копии 2995 картинок в формате WebP. Но одна галочка в его настройках была выключена, и сайт эти копии никому не отдавал.

Что сделали.

• Включили выдачу готовых WebP. Это формат картинок, который при том же качестве весит заметно меньше привычных JPG и PNG.
• Пережали 56 самых тяжёлых WebP: плагин делал их без потерь, и они получались почти такими же тяжёлыми, как оригиналы. Было 10,7 МБ, стало 1,1 МБ, минус 89%. Каждую картинку сравнили с оригиналом по пикселям, разница на глаз незаметна. Потом пережали ещё 794 файла: 123,7 МБ стали 90,3 МБ.
• Шесть больших картинок оформления сайта плагин вообще не видел: они лежат в папке темы, а не в медиатеке. Перевели их сами: 3094 КБ стали 191 КБ, минус 94%. Страница «О компании» после этого стала весить 702 КБ вместо 1637 КБ, а её первый экран стал появляться через 2,9 секунды вместо 8,3.
• Карусель на первом экране главной: 10 картинок в PNG весили 349 КБ, в WebP стали весить 82 КБ.
• Схемы на главной нарисованы в векторе, в формате SVG. Почистили их от лишнего кода специальной программой: 295 КБ стали 161 КБ. Каждую схему сверили с исходной по пикселям.
• В блоге карточки статей показывали обложки в полном размере, 1400 точек в ширину, хотя на экране они занимают в два раза меньше. Поставили нужный размер: самая тяжёлая обложка стала весить 58 КБ вместо 168 КБ.

На телефоне страница услуги теперь вообще не скачивает большую картинку первого экрана: на узком экране её всё равно не видно. Экономия 73 КБ на каждый заход.

Шаг 3. Главная картинка: браузер должен увидеть её сразу

Что видели. Самая важная метрика скорости показывает, когда человек увидел главное на первом экране. Обычно это крупная картинка или заголовок. На главной это был первый слайд карусели. И картинка весила всего 8 КБ, а появлялась на секунды позже текста.

Причина нашлась в том же плагине сжатия. Он подменял адрес картинки на пустышку, а настоящий адрес подставлял скриптом, когда страница уже загрузится. Пока скрипт не сработал, браузер просто не знал, что эту картинку надо качать. На главной так терялось 786 мс, на странице услуги 2234 мс.

Что сделали. Для картинки первого экрана выключили подмену и подсказали браузеру, что её надо качать в первую очередь. Ещё нашли ошибку в шаблоне карусели: пометка «качать первой» стояла не на одной картинке, а на всех десяти сразу, и они толкались в очереди. Оставили пометку только на первой.

Результат. Задержка перед загрузкой главной картинки: было 231 мс, стало 7 мс. После шагов 1–3 главная картинка на телефоне стала появляться через 3,1–3,4 секунды вместо 12,7.

Шаг 4. Убрали то, что грузилось зря

На каждой странице сайта грузились вещи, которые никто не использовал. По отдельности мелочь, вместе заметно.

• Вторая копия jQuery. Это библиотека, на которой работают кнопки, слайдеры и формы. WordPress уже подключал её, а тема подключала ещё одну, старую, на 87 КБ. Убрали дубль.
• Значки из админки. Набор иконок на 35 КБ нужен только в панели управления, а грузился каждому посетителю. Его тянул за собой плагин счётчика просмотров.
• Скрипт для смайликов, который сайту не нужен.
• Битая ссылка на каждой внутренней странице: картинка в меню была прописана неправильным адресом, и браузер каждый раз получал ошибку 404.
• Google Analytics на 156 КБ. Его не было в коде сайта, поэтому поиск по страницам ничего не находил. Оказалось, что его подгружал Яндекс Тег Менеджер, сервис для подключения счётчиков. Тег удалили и опубликовали изменения в сервисе: минус 156 КБ на каждой странице и минус 131 мс, когда телефон занят и не отвечает.

8 сентября за один день (Google Analytics, карусель и схемы) главная стала легче с 1391 до 833 КБ, а оценка выросла с 80 до 89.

Шаг 5. Сервер запоминает готовые страницы

Что видели. Каждый раз, когда человек открывал страницу, сервер собирал её заново: доставал текст из базы данных, подставлял в шаблон, собирал меню. На это уходило 0,6 секунды. И только потом страница начинала грузиться в браузер.

Что сделали. Настроили сервер так, чтобы он запоминал готовую страницу на 10 минут и отдавал её следующим посетителям сразу. Это называется кэш страниц. Опасность тут одна: если запомнить лишнее, перестанут работать формы. Поэтому заявки с форм, вход в админку и ссылки из рекламы идут мимо кэша. Когда мы публикуем или правим страницу, сайт сам стирает её старую копию.

Как проверили. Отправили настоящую тестовую заявку с сайта при включённом кэше. Письмо пришло. Отдельно убедились, что служебный запрос формы, который обновляет защиту от спама, тоже идёт мимо кэша.

Результат. Время, за которое сервер начинает отдавать страницу: было 0,6 секунды, стало 0,005 секунды, в 120 раз быстрее. С обычного ноутбука разница меньше, 0,66 против 0,41 секунды: остальное время занимает дорога данных по сети.

Шаг 6. Кэш жил минуту вместо десяти

Что видели. Через неделю после включения кэша в журнале ошибок сервера каждый день стало появляться по 600–1500 одинаковых строк. Разобрались: программа, которая стирает старые копии страниц, срабатывала на любое изменение настроек сайта. А WordPress меняет служебные настройки раз в минуту. В итоге кэш, рассчитанный на 10 минут, полностью стирался примерно каждые 75 секунд. Любая заявка с формы тоже стирала его целиком.

Что сделали. Переписали стирание. Теперь при правке страницы обновляются только она сама и связанные с ней страницы: главная, списки, рубрики, карта сайта. Полностью кэш сбрасывается, только когда меняется меню или оформление.

Результат. Ошибок в журнале за контрольный час: ноль. Страница остаётся в кэше и после служебных задач WordPress, и через полторы минуты. Правка одной страницы обновляет её, а соседние остаются в кэше.

Шаг 7. Скрипты после текста, сжатие сильнее, оформление по частям

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

Сжатие. Сервер сжимал файлы перед отправкой старым способом. Включили более сильный, Brotli: главная стала легче ещё на 10% по сети.

Оформление по частям. Все стили сайта лежали в одном большом файле, и каждая страница ждала его целиком, прежде чем что-то показать. Разделили его на общую часть и части для разных типов страниц: услуги, кейсы, блог. Главная теперь ждёт 18,8 КБ стилей вместо 81,7 КБ. Чтобы ничего не поехало, сравнили скриншоты страниц до и после по пикселям и сверили вычисленные стили каждого элемента.

Шаг 8. Страница больше не прыгает

Бывает так: страница появилась, человек тянется нажать кнопку, а она съезжает вниз, потому что сверху догрузился шрифт или картинка. Это раздражает и тоже учитывается поисковиком.

У нас было две причины. Шапка сайта при прокрутке меняла размер и двигала содержимое. А пока не загрузился фирменный шрифт, текст рисовался другим, более широким шрифтом, и когда приезжал свой, строки переносились по-новому. Шапку закрепили. Для шрифта подобрали запасной, который совпадает с фирменным по ширине букв. Иконкам в статьях задали точный размер.

Сейчас сдвиг вёрстки на всех замеренных страницах от 0 до 0,003. Хорошим Google считает всё, что меньше 0,1.

Почему скорость надо проверять после каждой выкладки

1 сентября, через два дня после первых правок, оценка главной упала с 83 до 56. На сайт за эти дни выложили другие изменения, и часть ускорения потерялась. На страницах услуг шрифты снова приезжали с огромной задержкой, а в блог вернулся ненужный набор значков.

Вернули за день: главная снова 77, раздел услуг 85, блог 80. Но главный вывод был другой. Мы написали проверку, которая после каждой выкладки за полминуты смотрит, на месте ли все прошлые правки: картинки в WebP, кэш, отключённые значки, шапка, контраст текста. И заявки по-прежнему идут мимо кэша. Сейчас в ней 37 пунктов.

Новое меню прошло тот же замер

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

Первая серия напугала: на телефоне главная картинка с новым меню появлялась через 4,8 секунды, без него через 2,2–2,7. Стали разбираться и увидели, что варианты мерились в разных условиях: один сервер отдавал из кэша, другой собирал заново. Когда условия выровняли, разница пропала. В обоих вариантах главная картинка появлялась примерно через 2,1 секунды. На компьютере с новым меню главная получает 98 баллов из 100.

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

Что мы сознательно не стали делать

В статьях про ускорение WordPress много советов, которые поднимают баллы, но вредят бизнесу. Вот что мы не делали и почему.

• Не откладывали и не отключали Яндекс Метрику. Это самый тяжёлый скрипт на многих страницах, без него баллы были бы выше. Но Яндекс учитывает поведение людей на сайте, а Метрика нужна, чтобы считать заявки. Сорок килобайт этого не стоят.
• Не отключали служебный интерфейс WordPress, через который работают формы. Его часто советуют выключить ради безопасности и скорости. У нас через него уходят заявки, а заявки с сайта для нас главное.
• Не ставили пачку плагинов для ускорения. Почти всё сделано несколькими строками в коде темы и настройками сервера. Каждый лишний плагин сам по себе тормозит сайт и может сломаться при обновлении.
• Не подключали сеть доставки контента, когда копии сайта лежат на серверах по всему миру. Сервер стоит в России, посетители тоже в России. Такая сеть не вылечила бы ни одну из найденных причин.
• Не ставили отдельное хранилище в памяти для базы данных. На сервере 2 ГБ памяти: такое хранилище отняло бы её у самой базы. Кэш готовых страниц на диске дал больше.
• Не гнались за баллами. Мы не удаляли нужное ради красивой цифры.

Результат

Все цифры ниже получены в Lighthouse с эмуляцией телефона через мобильный интернет. Это лабораторный замер, медиана трёх прогонов.

На компьютере главная получает 99 баллов из 100, главная картинка появляется через 0,8 секунды. Кейсы и статьи блога на компьютере получают 100.

Всего за пять недель около 25 отдельных правок, у каждой есть копия «до» и способ отката. Сайт работает на том же сервере, что и в августе. Форма заявки, Метрика и все счётчики работают.

Честно о том, чего мы пока не знаем. Данных о скорости у живых посетителей, которые собирает Google, по нашему сайту пока нет: для этого нужно больше трафика. Как ускорение повлияло на число заявок, мы тоже отдельно не считали. Это следующий шаг.

Что это значит для вашего сайта

Медленный сайт почти никогда не тормозит из-за одной причины. Обычно их десяток, и они очень разные по весу. У нас одна правка со шрифтами подняла оценку с 30 до 61, а пять мелких вместе дали несколько баллов. Смысл работы в том, чтобы найти тяжёлые причины и не тратить бюджет на мелочи.

Почти всё, что мы нашли у себя, встречается на других сайтах на WordPress и 1С-Битрикс:

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

Если ваш сайт открывается на телефоне дольше трёх секунд, начните с аудита быстродействия. За неделю мы разложим причины по весу и скажем, что внедрять первым. Сайт на WordPress можно передать нам на поддержку: скорость в ней проверяется после каждой выкладки.

Для технических специалистов

Окружение. WordPress 7.1, своя тема, 19 плагинов, PHP 8.3 с OPcache, nginx 1.24, VPS 2 vCPU / 2 ГБ RAM. Замеры: Lighthouse 13.4.1, эмуляция mobile, три прогона с прогревом кэша и отдельным ключом кэша на прогон, медиана.

• Шрифты: woff2, сабсет U+0020-00FF и U+0400-045F плюс ₽ и №; preload трёх начертаний на всех шаблонах; font-display: swap во всех 14 @font-face; запасные гарнитуры с size-adjust, ascent-override и descent-override под метрики SF Pro.
• Картинки: EWWW Image Optimizer, включена опция webp_for_cdn (JS-подмена в data-src-webp); тяжёлые WebP перегнаны через Imagick, q90, сверка попиксельно; картинки темы через image-set() с PNG-запасом и picture; для LCP-элемента класс skip-lazy, внесён в ewww_image_optimizer_webp_rewrite_exclude, fetchpriority=»high» и preload; хелпер lachatte_webp_url() отдаёт WebP в разметке; SVG через svgo с консервативным конфигом.
• Лишнее: дубль jQuery 3.3.1 снят (window.$ = window.jQuery для старого кода); jquery-migrate снят на фронте; dashicons от post-views-counter снят фильтром style_loader_tag; wp-emoji снят; GA4 удалён из контейнера Яндекс Тег Менеджера.
• Скрипты: defer для slick, fancybox, inputmask, main.js, front-page.js через script_loader_tag; Метрика остаётся без отложенной загрузки.
• Кэш HTML: nginx fastcgi_cache, зона на 32 МБ ключей и до 1 ГБ на диске, TTL 10 минут. Мимо кэша: маршруты Contact Form 7 в /wp-json/ (отправка и refill), залогиненные, адреса с utm-метками. Сброс: свой mu-плагин, точечный по записи и связанным архивам; вместо unlink() обнуляет version в заголовке файла кэша, nginx перезаписывает его сам. WP-CLI: wp lc-cache purge | status.
• Сервер: HTTP/2, Brotli (libnginx-mod-http-brotli), gzip для SVG, статика с expires max, HSTS.
• CSS: style.css минифицирован и разнесён на ядро и файлы по типам страниц, остальное грузится неблокирующе; сборка скриптом, сверка CSSOM и попиксельная сверка скриншотов; если исходник правили после сборки, отдаётся целиком.
• Контроль: скрипт проверки после выкладки (37 пунктов, включая HIT кэша, обход кэша для REST и отсутствие unlink() в error.log); тема под git; снимок «до» перед каждой правкой.