Сервер Shopify ответил за 0,73 секунды, первый контент отрисовался за 1,8 секунды. А главный элемент страницы появился только на 19,2 секунды, и загрузка закончилась на 27,4 секунды. Замерено на магазине, который мы давно ведём, инструментом WebPageTest: Chrome, мобильный профиль, холодный кэш, точка замера Токио, 24.06.2026.
Эти четыре числа - вся статья. Платформа была быстрой, медленной была страница. Это другой диагноз, другой виновник и главное - другое лечение. И разница между ними решает, потратите ли вы деньги на миграцию, которая ничего не исправит.
Сначала разделите замер на два числа, иначе будете чинить не то
Метрики скорости делятся на те, что принадлежат платформе, и те, что принадлежат вашей странице. Если читать их вместе, получается «Shopify тормозит» - вывод, который не лечится ничем, кроме переезда.
| Метрика | Замерено | Цель | Что на самом деле измеряет |
|---|---|---|---|
| TTFB | 0,73 с | - | ответ сервера платформы |
| FCP | 1,8 с | - | первый отрисованный контент |
| LCP | 19,2 с | до 2,5 с | главный элемент первого экрана |
| CLS | 1,00 | до 0,1 | сдвиг вёрстки во время загрузки |
| Fully Loaded | 27,4 с | - | завершение всех запросов |
Первые два числа хорошие. Если бы проблема была в инфраструктуре, медленным был бы уже TTFB: сервер отозвался бы за две-три секунды, и всё остальное сдвинулось бы следом. Здесь он отозвался за 0,73 секунды.
Точка замера в Токио для европейского магазина нетипична, и TTFB из Праги вышел бы другим. На соотношение между 1,8 и 19,2 секунды это не влияет: оба числа получены в одном прогоне, на одном канале.
Третья метрика Core Web Vitals, INP, в этом аудите не замерялась, потому что она считается из взаимодействий посетителя. Мы приводим только то, что измеряли.
Разница между 1,8 и 19,2 секунды весит 10,6 МБ
За один просмотр этой страницы браузер скачал 10,6 МБ данных в 548 запросах с 57 чужих доменов (тот же прогон WebPageTest, 24.06.2026). Пятьдесят семь доменов - это пятьдесят семь DNS-запросов, TLS-соединений и чужих серверов, на доступность которых вы не влияете.
Больше половины этого веса дал один элемент: видео на 5,7 МБ на первом экране, вставленное с autoplay: true. Такой атрибут запускает скачивание немедленно, независимо от качества связи, и пока не появится первый кадр, LCP не засчитывается. Одна строка в шаблоне перебивает всю остальную работу.
Собственный код темы весил 635 КБ. На живой странице их было три мегабайта
Когда мы разобрали локальную копию той же темы (27.08.2026), мы нашли в ней 32 собственных скрипта общим объёмом 635 КБ, и ни один из них не был подключён без атрибута defer. Собственный код был в порядке.
При этом на живой странице инструмент замера насчитал порядка 3 МБ JavaScript в 236 файлах. Разницу между 635 КБ и 3 МБ принесла не тема. Её принесли приложения и их внешние скрипты.
Практический вывод для бюджета: кто платит за рефакторинг темы и не трогает приложения, покупает меньшую часть проблемы. Что остаётся в теме после приложений, разбираем в статье про аудит приложений.
CLS 1,00 означает, что страница собирается дважды
Значение сдвига вёрстки 1,00 при цели 0,1 - это не ухудшенная метрика, это другая страница, чем та, которую посетитель видел секундой раньше. Две измеримые причины, обе из разбора темы от 27.08.2026:
- 577 тегов <img> в теме, из них 13 с атрибутом width (2 %) и 29 с loading (5 %). Браузер не знает, сколько места оставить под картинку, поэтому не оставляет никакого, а после загрузки сдвигает всё.
- 171 вызов stylesheet_tag в секциях и сниппетах. Каждый из них вставляет <link rel="stylesheet"> в тело документа, то есть уже после начала отрисовки.
По второму пункту мы осторожны: связь с замеренным CLS 1,00 вероятна, но мы её не подтвердили. Контрольного замера после переноса стилей в layout мы пока не делали, так что это остаётся гипотезой, а не находкой.
Фильтр image_tag сам добавляет размеры и srcset и закрывает вопрос на уровне шаблона. В этой теме он был использован в пяти файлах из всех.
Двенадцать чужих скриптов без defer - это двенадцать чужих отказов
В той же теме мы насчитали 12 внешних скриптов без атрибута defer или async с семи чужих хостов. Два из них синхронные прямо в <head> - там парсер останавливает обработку документа, пока файл не скачается с чужого сервера.
Это не только вопрос скорости. Это единая точка отказа: если тот чужой сервер не ответит, не отрисуется ничего. Один из хостов в той теме, polyfill.io, при нашей проверке 27.08.2026 возвращал ошибку HTTP 520.
PageSpeed Insights смешивает два разных замера, и только один - про вашу страницу
Инструмент показывает два набора чисел: лабораторную симуляцию, которая проходит сейчас и на заданном устройстве, и полевые данные от реальных посетителей за последние 28 дней. Когда значения расходятся, это не ошибка инструмента.
Это значит, что у ваших посетителей другие устройства и другой канал, чем у симуляции. Для решений действуют полевые данные, потому что в них сидят ваши клиенты. Лабораторное число годится на то, чтобы сравнить две версии страницы между собой в одинаковых условиях.
Порядок исправлений, в котором это делается
Порядок не произвольный. Первые пять пунктов на этой странице давали большую часть потерянного времени, остальное - косметика.
- Первый экран. Видео и главная картинка: постеры, размеры, loading="eager" и fetchpriority="high" на LCP-элемент.
- Инвентаризация приложений. Какие работают, какие оплачены и какие просто остались.
- Внешние скрипты. Что можно отложить, что можно захостить у себя, что должно уйти.
- Стили в layout. Критические инлайн, остальное асинхронно.
- Размеры картинок по всей теме, через image_tag.
- Контрольный замер в тех же условиях, иначе вы не знаете, что помогло.
Последний пункт пропускают чаще всего. Замер до исправления и после должен пройти на том же профиле, из того же места и с холодным кэшем, иначе вы сравниваете две разные вещи.
Чем платят за ускорение
Эту сторону надо проговорить вслух, потому что предложения по ускорению её обычно опускают. Когда вы снимаете приложение, вместе с ним исчезает функция, за которую вы платили - программа лояльности, отзывы о товарах, апселл в корзине.
Поэтому решение принадлежит не разработчику. Оно принадлежит тому, кто знает, сколько эта функция зарабатывает. Наша работа - дать вторую половину уравнения: сколько она стоит в данных, в секундах и в риске отказа.
Мы замеряем и собственный сайт, и у нас не сходится
Собственным инструментом мы 30.08.2026 замерили этот сайт на трёх ширинах экрана, и вышло от 5,3 до 5,6 МБ в 55-69 запросах. Для агентства, которое продаёт скорость, это неприятное число, и оно стоит в списке на исправление.
Мы приводим его здесь намеренно. Текст про скорость, в котором автор выглядит хорошо, вы прочтёте где угодно; полезен тот, где видны условия замера и дата, потому что только по ним вы проверите, действуют ли эти числа и для вас.
Хотите узнать, какие три вещи тормозят именно ваш магазин
Пришлите нам адрес магазина. Вернём разделение на то, что делает платформа, и то, что делает страница, с замеренными числами и с порядком исправлений по соотношению эффекта к цене.
Что именно мы измеряем в рамках аудита и ускорения сайта, описано на странице услуги. Если скорость для вас - часть большего вмешательства в тему, начните со статьи о том, как шаблоны выходят из-под контроля.
Напишите на info@lamapixel.com или позвоните +420 775 599 009.
