Сайт открывается очень медленно — это проблема дизайна или разработки? С этим вопросом сталкивается почти каждый, кто занимается корпоративным сайтом. Руководитель открывает официальный сайт, пять секунд смотрит на крутящийся индикатор и первым делом думает: «Наверное, сервер слишком слабый». Но в реальности всё иначе: сервер — лишь часть проблемы, а дизайн и разработка вносят очень большой вклад.
Я видел типичную ситуацию: компания, производящая оборудование, после редизайна официального сайта получила главную страницу, которая стала загружаться не за 2 секунды, а за 8. Руководитель решил, что дело в дата-центре, сменил двух хостинг-провайдеров, но сайт всё равно оставался медленным. В итоге выяснилось, что в дизайн-макете на главной странице было размещено 12 изображений в высоком разрешении, а разработчик не сделал ни сжатие, ни ленивую загрузку, и первый экран одновременно запрашивал более 30 ресурсов.
Поэтому на этот вопрос нельзя отвечать наугад. Ниже разберём всё по порядку диагностики.
一、Сначала разберёмся с тремя типами «медленно»
Медленное открытие — это не одна болезнь, а как минимум три:
- Долгий белый экран первого экрана: после клика по ссылке долго ничего не отображается; обычно это большой объём ресурсов, медленные API или блокирующие скрипты.
- Страница открывается, но взаимодействие тормозит: страница появилась, но прокрутка, клики и переключение вкладок подтормаживают; чаще всего это слишком тяжёлая фронтенд-логика или анимации.
- То быстро, то медленно: днём медленно, вечером быстро, или в некоторых регионах медленно; чаще всего это пропускная способность, CDN или конфигурация сервера.
Сначала определите, какой это тип, а уже потом говорите о том, кто несёт ответственность. Иначе легко получить перекладывание вины: «дизайн говорит, что разработка не оптимизировала», а «разработка говорит, что макеты слишком тяжёлые».
二、Уровень дизайна: визуальный макет может изначально заложить мину
Дизайн — это не только «нарисовать красиво», дизайнерские решения напрямую определяют вес страницы. Типичные ловушки:
1. Нереалистично большие изображения на первом экране: одно 4K-изображение сразу ставится на первый экран, да ещё и с требованием не сжимать.
2. Слишком много шрифтов: на одной странице подключается четыре-пять китайских шрифтов, каждый по несколько сотен KB, и загрузка естественно замедляется.
3. Наложение анимаций: анимации входа, анимации при прокрутке, параллакс-эффекты — всё сразу; на мобильных устройствах это приводит к зависанию.
4. Нет спецификаций для изображений: в макете есть только внешний вид, но нет рекомендаций по размерам и форматам, и разработчику приходится использовать всё как есть.
Способ избежать этих проблем прост: ещё на этапе дизайна договориться, что главное изображение первого экрана не превышает 300KB, на всём сайте не более двух китайских шрифтов, а из анимаций остаются только одна-две необходимые. Это не ограничение креатива, а условие того, что креатив вообще сможет работать.
三、Уровень разработки: проблемы производительности чаще всего кроются здесь
Если сам макет нормальный, нужно смотреть на этап разработки сайта. Типичные слабые места производительности:
- Изображения не сжаты, не переведены в WebP, не сделана ленивая загрузка — это самая частая и самая легко исправимая категория.
- Последовательные вызовы API: главная страница ждёт ответа от API A, прежде чем запросить API B, и напрасно теряет несколько сотен миллисекунд.
- Слишком много сторонних скриптов: аналитика, чат поддержки, карты, рекламные плагины — по одному каждого, и каждый замедляет первый экран.
- Нет стратегии кэширования: при каждом посещении заново загружаются все данные, сервер испытывает большую нагрузку, а пользователь долго ждёт.
- Фронтенд-сборка не разделена: JS-файл размером несколько MB загружается целиком, и первый экран неизбежно будет медленным.
Есть простой приём для оценки: посмотрите панель Network в инструментах разработчика браузера. Если на первом экране больше 50 запросов или отдельный ресурс превышает 1MB, почти наверняка оптимизация на стороне разработки выполнена не полностью.
四、Сервер и развёртывание: не считайте это единственной причиной, но и не игнорируйте
Сервер действительно влияет на скорость, но обычно он не является главной причиной медленного первого экрана. Обратить внимание стоит на следующее:
- Достаточно ли пропускной способности, особенно для корпоративных сайтов с большим количеством изображений.
- Подключён ли CDN, распределены ли статические ресурсы по узлам, близким к пользователю.
- Есть ли медленные запросы к базе данных; особенно это заметно в админ-панелях.
- Включено ли сжатие Gzip или Brotli.
Распространённое заблуждение: тратить большие деньги на апгрейд сервера, но не делать сжатие изображений. В итоге деньги потрачены, а скорость выросла совсем немного. Правильный порядок — сначала оптимизировать фронтенд-ресурсы, а уже потом думать о добавлении мощностей.
五、Конкретные сценарии: почему мини-программы записи и админ-системы тоже тормозят
Это касается не только корпоративных сайтов; разработка мини-программ и разработка App тоже сталкиваются с похожими проблемами.
Например, в мини-программе для записи пользователь после открытия ждёт три секунды, прежде чем увидеть доступное время. При диагностике выяснилось: при входе на страницу одновременно запрашивались четыре API — список филиалов, услуги, информация о пользователе и доступные интервалы, — и кэширование не использовалось. После того как сделали сначала отрисовку skeleton-экрана, параллельные запросы к API и локальное кэширование данных по интервалам, первый экран стал загружаться менее чем за 1 секунду.
Ещё пример: в админ-системе страница списка при каждом перелистывании заново запрашивала всю таблицу. После добавления индексов и кэширования пагинации время отклика снизилось с 4 секунд до 300 миллисекунд.
Это не проблема дизайна и не полностью проблема сервера, а проблема осознания производительности на этапе разработки.
六、В каких случаях стоит обратиться в MIC Studio
Если вы уже проверили всё в указанном порядке, но так и не нашли причину, или в команде нет человека, который одновременно разбирается в дизайне, фронтенде, бэкенде и развёртывании, тогда стоит привлечь профессиональную команду.
MIC Studio занимается корпоративными сайтами, разработкой мини-программ, разработкой App и разработкой скриптов, а также тестированием безопасности сайтов и reverse-тестированием. Наш подход к таким задачам: сначала измерить скорость и локализовать проблему, затем дать список оптимизаций и вносить изменения по приоритету, а не сразу предлагать всё переделывать.
Когда стоит обращаться к нам:
- После редизайна официального сайта он заметно замедлился, и вы не можете найти причину самостоятельно;
- Первый экран мини-программы или App загружается дольше 3 секунд и влияет на конверсию;
- Админ-система чем дальше, тем сильнее тормозит, а с ростом объёма данных отклик становится очень медленным;
- Нужен выполнимый план оптимизации производительности, а не общие «рекомендации по оптимизации».
Заключение: три выполнимых совета
1. Сначала измерьте, потом меняйте: с помощью инструментов разработчика или сервисов замера скорости зафиксируйте время первого экрана, количество запросов и размер ресурсов; опирайтесь на данные, а не на ощущения при замене сервера.
2. Дизайн и разработка должны договориться заранее: уже на этапе визуального макета согласуйте спецификации изображений, количество шрифтов и объём анимаций — это сэкономит много переделок на поздних этапах.
3. Не перепутайте порядок оптимизации: сначала сжатие изображений, сокращение запросов и кэширование, и только потом апгрейд пропускной способности и сервера — так выгоднее всего.
Медленный сайт — не страшно; страшно постоянно гадать. Разбейте проблему на три блока — дизайн, разработка, развёртывание — и проверяйте их по очереди; ответ найдётся сам.