Сайты девелоперов почти всегда тормозят. Причина простая: на них очень много тяжёлой графики. Интерактивные генпланы, обводки этажей, планировки в SVG, рендеры, галереи. Всё это надо показать человеку красиво и быстро, а оно по своей природе весит много и грузится долго.
А цена медленного сайта вполне конкретная. Человек ждёт, пока откроется планировка, пару секунд ничего не происходит, и он уходит к конкуренту, у которого открылось сразу. Google и Яндекс тоже всё это видят и понижают медленный сайт в выдаче. Так что скорость тут не про «приятно», а про заявки и про позиции.
Мы занимались оптимизацией скорости сайтов у застройщиков не раз и не два. Это отдельная большая задача по оптимизации, на которую закладывается достаточное количество часов, и ещё куча точечных подходов потом. Расскажем, на что реально уходит время, где мы упёрлись в стену и что в итоге сработало. Сразу скажу: волшебной кнопки «сделать быстро» не существует, это всегда кропотливая работа в нескольких местах сразу.
Сначала разобрались, что именно тормозит
Первое, чему пришлось научиться, — не оптимизировать вслепую. Соблазн большой: взял, навешал ленивую загрузку везде, где можно, и отчитался. Толку от этого мало, а иногда и вред.
Мы гоняли сайт через Google PageSpeed и смотрели, на что он ругается. А ругался он на разное. Где-то картинки без заданных размеров, и страница дёргается при загрузке, пока браузер не понял, сколько места под них отвести. Где-то сервер слишком долго отдаёт первый байт. Где-то тяжёлый скрипт блокирует отрисовку. Это всё разные болезни, и лечатся они по-разному. Поэтому мы сначала всегда замеряли и смотрели, что именно тормозит на конкретной странице, и только потом чинили.
Картинки: главный вес и главный резерв
На сайте застройщика основной вес — это изображения. И именно тут лежит самый большой и быстрый выигрыш.
Мы написали скрипт, который нарезает каждое фото под все нужные разрешения экрана. Браузер на телефоне тянет лёгкую версию, а не ту же гигантскую картинку, что уходит на большой монитор. Звучит банально, но именно это PageSpeed требовал в первую очередь, и именно это сильнее всего разгрузило мобильную версию. Отдельно для главного экрана мы потом завели возможность подставлять вообще отдельную картинку под мобильные — то, что хорошо смотрится на десктопе, на узком экране часто выглядит плохо.
Ещё одна мелочь, которая на самом деле не мелочь. Мы проставили всем изображениям атрибуты ширины и высоты. Без них браузер не знает заранее, сколько места займёт картинка, и страница прыгает по мере загрузки. Человека это бесит, а поисковик считает это отдельной проблемой и штрафует. Полчаса работы, заметный эффект.
Ленивая загрузка — там, где она к месту
Дальше — ленивая загрузка. Смысл в том, чтобы не грузить сразу всё, что есть на странице, а подтягивать по мере того, как человек до этого доскроллит. Но при этом она должна быть заблаговременной, чтобы пользователь не ждал подгрузки и не рассматривал прелоадер.
В каталоге мы переделали вывод секций под ленивую загрузку и сделали ленивую пагинацию: квартиры подгружаются порциями, а не вываливаются все разом. На главной так же подтягиваются тяжёлые блоки ниже первого экрана. Пока человек смотрит первый экран, остальное ещё даже не загружено, и до него очередь дойдёт, только когда он начнёт листать.
Но тут есть важная оговорка, которую мы выучили на практике. Ленивая загрузка — не панацея, и делать её везде нельзя. На одном из проектов пришлось наоборот найти по всему сайту ленивую загрузку картинок и отключить, потому что она там мешала и ломала поведение. Так что это инструмент под конкретное место, а не галочка «включить везде и забыть».
Тяжёлые SVG: когда красивая схема душит браузер
Отдельная головная боль на сайте застройщика — интерактивные планы. Особенно паркинг.
План паркинга на несколько сотен машиномест — это SVG с диким количеством элементов. И он реально начинает подтормаживать: наводишь курсор, а схема думает. Мы с этим возились отдельно, разбирались, почему планировка паркинга так долго грузится. Тут оптимизация упирается не в кэш и не в картинки, а в сам объём векторной графики. Иногда правильное решение — упростить схему, убрать часть лишней детализации, которую человек всё равно не замечает, но которая стоит браузеру отрисовки сотен полигонов. План, который мгновенно реагирует на наведение, полезнее того, что красивее, но думает три секунды.
Кэширование: чтобы сервер не считал одно и то же заново
Когда с картинками и графикой разобрались, осталась серверная часть — как быстро сайт вообще отдаёт страницу.
Сначала мы сделали кэширование основных запросов средствами самого Django. Это уже дало эффект: часто запрашиваемые данные сервер перестал собирать каждый раз заново. Потом перешли на Redis, прописали кэш для всех тяжёлых запросов и аккуратно настроили его сброс. Тут был тонкий момент: чистить кэш надо, не задевая пользовательские сессии, иначе людей будет выкидывать. Пришлось отдельно разбираться, как удалять кэш выборочно.
И вот где вылез неочевидный баг. На сайте застройщика данные живут не сами по себе, они приезжают из 1С при выгрузке квартир. Получилось так, что после выгрузки кэш не сбрасывался как надо, и сайт какое-то время показывал старые цены и остатки. Лечили это автоматическим сбросом кэша сразу после каждой выгрузки, чтобы свежие данные подхватывались без ручного вмешательства. А ещё пришлось отдельно проследить, чтобы личные данные пользователя при заходе не кэшировались, иначе один человек мог увидеть чужое состояние.
Где мы реально застряли: первый байт и Docker
Самая неприятная часть истории — скорость отдачи первого байта. Это время, за которое сервер вообще начинает отвечать, и PageSpeed на него ругался отдельно.
Логичный первый ход — добавить серверу ресурсов. Подняли CPU и RAM. И нам это не помогло вообще. Стали разбираться почему. Выяснилось, что дело не в железе, а в том, что Docker не разбирал нагрузку на все ядра. Мы даже проверили это на своей локалке: контейнер бэкенда пыхтит на все сто процентов, а виртуалка при этом забирает всего шесть-семь процентов ресурсов машины. То есть мощности есть, но сайт их не берёт. Корень оказался в особенностях многопоточности Python, и быстрым добавлением гигабайтов эта штука не лечится. Это была хорошая прививка от иллюзии «купим сервер помощнее и всё разлетится».
Параллельно бодались с кэшированием статики на nginx. Включить его удалось, но он конфликтовал с файрволом, и кэш пришлось откатить. Пробовали CDN: подключили, трафик через него пошёл, а PageSpeed всё равно ругался на кэш изображений. В итоге настроили правила кэширования прямо на бакете. Только после этого претензии по статике у PageSpeed закончились.
Что из этого полезно застройщику
Если убрать технические детали, выводов получается несколько.
Скорость сайта — это деньги, а не косметика. Медленная планировка теряет покупателя ровно в тот момент, когда он уже заинтересовался, а низкая оценка PageSpeed тянет вниз позиции в поиске. На сайте застройщика, где трафик дорогой, это считается напрямую.
Браться надо с замеров, а не с догадок. Мы каждый раз сначала смотрели, на что жалуется PageSpeed, и только потом чинили. Иначе легко потратить неделю на то, что почти не влияет.
И главное, в чём мы убедились на своём опыте: быстрый сайт застройщика — это не одна большая победа, а десяток мелких.
- Нарезка картинок под разрешения, размеры у изображений.
- Ленивая загрузка там, где она уместна.
- Упрощённые тяжёлые SVG.
- Кэш на сервере с правильным сбросом после выгрузки из 1С.
- И т.д.
По отдельности каждая опция даёт немного. А вместе из медленного тяжёлого сайта получается тот, на котором планировка открывается сразу и пользователь остаётся.
