NovСкорость страницы нельзя улучшать ценой нужной функции
Почему производительность важна, но удаление полезного сравнения или источников ради метрики может сделать сайт хуже.
Материал отражает практическую позицию указанного эксперта. Как готовятся и проверяются публикации — в редакционной политике NovAsia.
Производительность легко превратить в соревнование за красивый показатель. Я люблю быстрые страницы, но не считаю победой ситуацию, когда сайт ускорили, удалив полезное сравнение, источник или фильтр.
На страницах проектов NovAsia есть изображения, фильтры, статусы и действия пользователя. Скорость имеет смысл только пока эти функции остаются рабочими и доступными в тот момент, когда они нужны.
Сначала нужно понять, что именно тормозит полезное действие
Одна и та же страница может выглядеть быстрой и ощущаться медленной. Первый экран уже появился, но фильтр не реагирует. Карточка открылась, а галерея блокирует прокрутку. Кнопка видна, но сценарий сравнения ещё не готов. Поэтому я смотрю не только на момент появления контента, а на путь до первого полезного действия.
Чаще всего оптимизация начинается со скучных вещей: размеры изображений, порядок загрузки скриптов, шрифты, кэш, тяжёлые зависимости, повторные запросы и код, который выполняется раньше, чем он понадобится. Эта работа редко выглядит эффектно, зато позволяет сохранить функции.
Если дорогой по производительности блок нужен только ниже по странице, его необязательно готовить одновременно с первым экраном. Если большая библиотека используется ради одной мелкой функции, стоит проверить, нельзя ли решить задачу проще. Здесь цель не «удалить всё тяжёлое», а не заставлять пользователя оплачивать загрузкой то, чем он пока не пользуется.
Метрика не знает, зачем человек открыл страницу
Автоматический отчёт может честно показать техническую проблему, но он не понимает ценность конкретного элемента для решения пользователя. Источник, предупреждение или сравнение могут занимать место и требовать дополнительного кода, однако их удаление делает страницу беднее по смыслу.
Поэтому любой компромисс я рассматриваю вместе с функцией. Что получает человек за дополнительное время загрузки? Можно ли дать ту же пользу дешевле? Нужен ли элемент сразу или позже? Есть ли облегчённое представление на мобильном без потери существенной информации?
Такой подход защищает от странной оптимизации, когда показатель улучшается, а человек вынужден открыть три дополнительные страницы, чтобы получить то, что раньше было рядом.
Быстрая страница должна оставаться устойчивой после развития
Есть ещё одна ловушка: разовая оптимизация. Сегодня страница быстрая, через месяц новый виджет добавил тяжёлый сценарий, затем аналитика подключила ещё один скрипт, потом увеличились изображения — и первоначальный результат исчез.
Мне ближе постоянная техническая дисциплина: новые функции оцениваются не только по тому, работают ли они, но и по тому, сколько они добавляют к критическому пути. Если компонент можно загрузить позже, не стоит помещать его в начало. Если одно изменение заметно ухудшает поведение страницы, причина должна быть понятна до массового релиза.
Мне нужен не самый лёгкий сайт. Мне нужен сайт, который быстро становится полезным и не выбрасывает ради скорости то, зачем человек его открыл.