Почему скорость сайта начинается с решений в дизайне

Почему скорость сайта начинается с решений в дизайне

Иван Проскуряков
Автор статьи

Иван Проскуряков

Веб дизайнРазработка

Скорость сайта часто вспоминают слишком поздно. Макет уже утвержден, анимации понравились, на первом экране стоит тяжелое видео, в каждом блоке свои декоративные карточки, шрифтов три семейства, и только потом кто-то открывает Lighthouse и грустнеет.

Проблема не в том, что разработчик плохо "оптимизировал". Иногда сайт становится тяжелым еще до первой строки кода. Дизайн-решения тоже имеют вес: в килобайтах, запросах, времени рендера, поддержке и мобильной боли.

Красивая картинка может быть дорогой

Изображения обычно дают самый быстрый визуальный эффект и самый простой способ утяжелить страницу.

Особенно опасны:

  • большие фоновые фотографии на первом экране;
  • слайдеры, где сразу грузится несколько крупных картинок;
  • декоративные PNG там, где хватило бы CSS или SVG;
  • фотографии без понятного размера и кадрирования;
  • одинаковые изображения в разных вариантах для desktop и mobile без контроля веса.

Я не против хороших изображений. Сайт без нормального визуала часто выглядит бедно. Но картинка должна работать: показывать продукт, услугу, результат, процесс или доверие. Если изображение просто "для атмосферы", его вес надо защищать особенно жестко.

Практичная проверка простая: если убрать картинку, смысл блока исчезает или нет? Если не исчезает, возможно, это не контент, а дорогой декор.

Эффекты надо покупать осознанно

Анимации, параллакс, плавные появления, сложные маски, бегущие строки и 3D-превью могут быть уместны. Но у каждого эффекта есть цена.

Иногда цена нормальная: маленький hover, аккуратное раскрытие меню, понятное состояние кнопки. Это помогает интерфейсу.

Иногда цена странная:

РешениеЧто может стоить
Видео на первом экраневес, автозагрузка, проблемы на мобильном
Параллакс в нескольких секцияхрывки при скролле, сложная поддержка
Большая canvas-сценаотдельная логика, нагрузка на слабых устройствах
Анимация каждого блокалишний JavaScript и задержка восприятия
Карусель вместо спискабольше кода, хуже доступность, меньше контроля

Главный вопрос не "можем ли сделать". Конечно можем. Вопрос: что человек поймет быстрее после этого эффекта? Если ответ мутный, эффект лучше оставить в папке красивых идей, а не в production.

Шрифты тоже не бесплатные

Шрифты любят недооценивать. Кажется, что это просто часть визуального стиля. Но каждое семейство, начертание и вес добавляют загрузку и могут влиять на то, как быстро появляется текст.

Для обычного сайта услуг часто достаточно:

  • одного основного семейства;
  • двух-трех начертаний;
  • системного fallback;
  • аккуратных размеров и межстрочных интервалов.

Если в макете есть отдельный шрифт для заголовков, другой для текста, третий для акцентов и еще несколько жирностей "на всякий случай", это не премиальность. Это будущий спор с производительностью и поддержкой.

Хорошая типографика начинается не с количества шрифтов, а с иерархии. Заголовок, подзаголовок, текст, подпись, кнопка. Если эти роли понятны, сайт уже выглядит собраннее. Даже без цирка из пяти гарнитур.

Сетка влияет на скорость разработки и рендера

Сложная сетка может быть красивой на макете и дорогой в реальной жизни. Особенно когда каждый блок живет по своим правилам: где-то карточки в шахматном порядке, где-то нестандартные отступы, где-то текст поверх изображения, где-то декоративный слой с абсолютным позиционированием.

Это бьет не только по браузеру. Это бьет по скорости разработки:

  • адаптив становится ручной настройкой каждого блока;
  • контент нельзя заменить без риска сломать композицию;
  • длинные заголовки начинают вылезать из карточек;
  • редактору приходится подгонять текст под дизайн;
  • новая секция требует почти новый компонент.

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

Дизайн должен учитывать реальный контент

Многие тяжелые решения появляются из-за пустоты. В макете нет реальных фотографий, кейсов, текстов и ограничений, поэтому туда кладут эффекты, большие декоративные блоки и красивые заглушки.

Потом приходит настоящий контент:

  • длинное название услуги;
  • обычная фотография с телефона;
  • таблица тарифов;
  • пять пунктов вместо трех;
  • юридический текст;
  • FAQ с неудобными вопросами;
  • форма с обязательным согласием.

И внезапно выясняется, что легкий красивый макет был легким только потому, что в нем не было жизни.

Я бы начинал дизайн с грубого контента: реальные заголовки, реальные ограничения, реальные изображения хотя бы приблизительного качества. Тогда быстрее видно, где нужен визуальный прием, а где достаточно нормальной структуры.

Что обсудить до утверждения макета

Перед тем как закреплять дизайн, полезно пройти короткий список:

  1. Какие изображения грузятся на первом экране.
  2. Есть ли тяжелое видео или можно заменить его статичным превью.
  3. Сколько шрифтов и начертаний реально нужно.
  4. Какие эффекты помогают понять страницу, а какие просто украшают.
  5. Что будет на мобильном при медленном интернете.
  6. Как блоки поведут себя с длинным текстом.
  7. Можно ли переиспользовать секции без отдельной верстки каждый раз.
  8. Какие сторонние скрипты нужны сразу, а какие можно не ставить.

Это не попытка убить дизайн. Это нормальная инженерная гигиена. Лучше один раз обсудить цену решения до разработки, чем потом героически вырезать половину красоты перед запуском рекламы.

Минимальный принцип

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

Хорошая фотография продукта отрабатывает. Понятная схема процесса отрабатывает. Аккуратная анимация состояния кнопки отрабатывает. Тяжелый фон "для настроения", который никто не помнит через пять секунд, скорее всего, нет.

Скорость начинается не в момент оптимизации. Она начинается, когда команда выбирает, что вообще попадет на страницу.

Итог

Быстрый сайт нельзя просто "докрутить" в конце, если дизайн уже заложил в него лишний вес. Код важен, но он не отменяет решений, принятых в макете.

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

Похожие статьи

Вам будет интересно