Оптимизация сайта. Этап 2.

Техническая оптимизация renter.moscow по результатам Этапа 1 и финального отчёта.

Этап 2 — до 7 календарных дней.

Цель этапа: уменьшить реальную стоимость загрузки первого экрана и количество лишнего JS/изображений, не ухудшая мобильный UX и полноту основной аналитики.
1. Manrope / первый paint

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

* сохранить визуальный вид сайта;
* проверить отсутствие заметного layout shift;
* проверить главную страницу на desktop/mobile;
* выполнить не менее 10 последовательных Lighthouse Mobile прогонов после изменения;
* дополнительно снять PageSpeed Insights;
* в отчёте показать FCP, LCP, TBT, CLS, Performance по серии запусков и сравнение с состоянием до изменения.

Это экспериментальная оптимизация, без гарантии конкретного значения Lighthouse LCP. Если визуально или технически есть проблема — вернуть предыдущий вариант.

2. Изображения ниже первого экрана

Оптимизировать изображения, которые сейчас грузятся сразу, хотя находятся ниже первого экрана, в частности выявленные в отчёте car_baner2.webp и long.jpg.

* lazy-load для действительно ниже-fold изображений;
* не применять lazy-load к LCP/первому экрану;
* проверить waterfall;
* проверить мобильную версию.

3. Responsive images

Для подходящих изображений внедрить srcset/sizes либо эквивалентный механизм Tilda, если он технически корректен.

Цель — не загружать на мобильном изображение существенно большего размера, чем требуется фактическим отображением.

4. Проверка форматов изображений

Проверить изображения первого экрана и ниже fold на возможность WebP/AVIF без видимой потери качества.

Конвертировать только там, где это даёт реальный выигрыш по передаваемому весу.

5. Tilda / Zero Block

Провести анализ HTML страницы и Zero Block на предмет очевидного избыточного кода.

Найти и предложить конкретные элементы, которые можно:

* удалить;
* объединить;
* заменить более лёгким решением.

Не переписывать сайт целиком и не менять дизайн без отдельного согласования.

6. CSS / JS Tilda

Проверить waterfall и main-thread на предмет JS/CSS, которые не нужны для первого экрана.

Для реально некритичных ресурсов предложить defer/delay либо другое безопасное решение.

Не отключать системные скрипты Tilda вслепую.

7. Metrica

Оставить production в текущем режиме с полной загрузкой Metrica, пока отдельно не согласован переход на Режим 2.

Проверить, можно ли уменьшить влияние tag.js/tag_phono.js на main-thread без потери:

* визитов;
* UTM/yclid;
* целей;
* работы колл-трекинга, если он используется.

Если безопасного решения без потери данных нет — зафиксировать это в отчёте, ничего не ломать.

8. Режим 2

`/m2-test` оставить как тестовую копию.

Не переводить production на Mode 2 без моего отдельного сообщения в чате.

Если предлагается иной способ отложенной загрузки Metrica — сначала показать способ и потенциальные потери данных, затем согласовать.

9. Проверка мобильного UX

После всех изменений проверить:

* первый экран;
* меню;
* основные CTA;
* Telegram;
* MAX;
* телефон;
* формы/кнопки;
* отсутствие визуальных скачков и задержек при первом взаимодействии.

Проверка минимум на Android Chrome и iPhone Safari через мобильный интернет.

10. Измерения ДО / ПОСЛЕ

Перед изменениями зафиксировать baseline.

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

Минимум:

* 5 последовательных Lighthouse Mobile прогонов после всех изменений;
* PageSpeed Insights;
* сравнение с baseline Этапа 1;
* FCP;
* LCP;
* TBT;
* CLS;
* Performance;
* Total Byte Weight;
* краткий анализ waterfall.

Указать медиану серии и диапазон значений, а не только лучший запуск.

11. Реальные пользователи

Не считать исправленным проблему только на основании одного Lighthouse/PSI запуска.

Если результат зависит от Chrome PaintHolding/headless, отдельно показывать:

1. официальный Lighthouse/PSI результат;
2. диагностический результат без PaintHolding, если он используется.

Не выдавать второй показатель за официальный LCP.

12. Финальный отчёт

В финальном отчёте отдельно указать:

* что изменено;
* где именно изменено;
* что дало измеримый эффект;
* что эффекта не дало;
* что осталось тяжёлым;
* что не рекомендуется трогать;
* какие оптимизации требуют отдельного следующего этапа.

Приёмка Этапа 2

Этап считается выполненным при одновременном выполнении условий:

1. Все согласованные пункты 1–8, которые технически возможно реализовать без изменения дизайна, опубликованы.
2. Мобильная версия и основные CTA работают как до изменений.
3. 4 пользовательские цели продолжают срабатывать по одному разу на действие.
4. UTM и yclid продолжают передаваться в параметры визита.
5. CLS не ухудшился относительно Этапа 1 и остаётся ≤0,1.
6. Вес первого запуска не должен увеличиться относительно baseline Этапа 1 без отдельного согласования.
7. В финальном отчёте есть серия из 5-10 Lighthouse Mobile запусков и сравнение ДО/ПОСЛЕ.