Адаптивная вёрстка: как один сайт перестраивается под телефон, планшет и ноутбук

Адаптивная вёрстка — способ собрать страницу так, чтобы один и тот же код по одному адресу перестраивался под ширину экрана: на телефоне блоки встают друг под друга, на ноутбуке расходятся в ряд. Держится она на трёх вещах — метатеге viewport, гибкой сетке и медиа-запросах CSS. Google называет такой подход самым простым в работе, а Яндекс ждёт, что страница откроется без горизонтальной прокрутки на экране от 320 пикселей.

Что такое адаптивная вёрстка

При адаптивной вёрстке сервер отдаёт всем устройствам один и тот же HTML, а браузер сам решает, как нарисовать страницу на конкретном экране. В справке Google так и сказано: код один для компьютеров, планшетов и телефонов, а отрисовка зависит от размера экрана. У Яндекса формулировка короче: сайт подстраивается под разрешение и размер экрана и доступен по одному URL для всех типов устройств.

«Адаптивный дизайн» и «адаптивную вёрстку» часто путают. Дизайн — это макеты: дизайнер рисует, как блоки стоят на узком, среднем и широком экране. Вёрстка — код на HTML и CSS, который превращает макеты в работающую страницу: задаёт сетку, правила перестройки и размеры элементов. Можно нарисовать три аккуратных макета и сверстать их так, что на ширине между ними всё развалится. Заказчику поэтому важен результат вёрстки, а не число макетов.

Для бизнеса адаптив значит простую вещь. Человек с телефона видит те же цены, контакты и форму заявки, что и с компьютера, и ему не нужно растягивать страницу пальцами, чтобы прочитать текст.

Факт. Google индексирует и ранжирует мобильную версию сайта, которую сканирует Googlebot для смартфонов. При адаптивной вёрстке мобильная и полная версии получают одинаковый контент и метаданные.

Чем адаптив отличается от динамической вёрстки и мобильной версии?

Подстроить сайт под телефон можно тремя способами, и справки поисковиков описывают все три. Адаптивная вёрстка отдаёт один код по одному адресу. Динамическая вёрстка (Google называет её динамическим показом) по тому же адресу отдаёт разный HTML и CSS в зависимости от устройства. Мобильная версия живёт на отдельном адресе, обычно на поддомене вида m.example.com, и держится на редиректах и связке с основной версией.

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

Мнение. Если у сайта нет причины показывать телефону другой набор функций, берите адаптивную вёрстку: одна страница, один адрес, одна правка вместо трёх. Подробно о выборе — в разборе адаптивного дизайна и отдельной мобильной версии.

Зачем странице метатег viewport?

Метатег viewport — первая строка адаптивной вёрстки: без него телефон не знает, что страница умеет перестраиваться. Мобильный браузер по умолчанию рисует страницу так, будто у него экран настольного компьютера, обычно около 980 пикселей в ширину, а потом уменьшает её до размера телефона. Текст мельчает, и человек вынужден увеличивать страницу пальцами.

Исправляет это одна строка в разделе head:

<meta name="viewport" content="width=device-width, initial-scale=1">

Значение width=device-width говорит браузеру, что ширина страницы равна ширине экрана в пикселях, не зависящих от устройства. Это не физические точки матрицы: на плотном экране один такой пиксель складывается из нескольких физических. Часть initial-scale=1 отключает начальное масштабирование.

Яндекс советует тот же тег всем сайтам с адаптивным дизайном. Но тег без гибкой сетки ничего не спасёт — он лишь перестаёт обманывать браузер. Если блоки свёрстаны жёсткой шириной, после viewport они просто вылезут за край экрана.

Метатег viewport не делает сайт адаптивным. Он разрешает браузеру показать адаптивность, если она заложена в CSS.

Как гибкая сетка и картинки подстраиваются под экран

Гибкая сетка — раскладка, в которой ширину колонок задают долями свободного места, а не жёсткими пикселями. На широком экране три карточки встают в ряд, на узком та же сетка перестраивает их в столбец, и никто не пишет для этого отдельную страницу. По справке web.dev, Flexbox, Grid Layout и Multicol значительно упрощают создание таких гибких сеток.

Flexbox удобен для ряда элементов разного размера: пунктов меню, кнопок, тегов, которые переносятся на новую строку, когда им тесно. Grid нужен, когда у страницы есть настоящая сетка из строк и колонок — каталог, галерея, блок «товар и характеристики». Колонки в Grid задают единицей fr, то есть частью свободного места в контейнере.

Картинки — частая причина горизонтальной прокрутки. Изображение с фиксированной шириной больше экрана вытягивает за собой всю страницу, и она начинает ездить вбок под пальцем. web.dev советует по умолчанию ограничить все изображения шириной контейнера:

img {
  max-width: 100%;
  height: auto;
}

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

Как работают медиа-запросы CSS

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

Условный пример: на узком экране карточки идут столбцом, а начиная с заданной ширины встают в три колонки.

.cards { display: grid; gap: 1rem; }

@media (min-width: 40em) {
  .cards { grid-template-columns: repeat(3, 1fr); }
}

Ширину в медиа-запросах удобнее задавать в em, а не в пикселях. Тогда перестройка сдвигается вместе со шрифтом, если человек увеличил его в настройках браузера, и крупный текст не упирается в узкие колонки.

Медиа-запросы проверяют не только ширину. Признаки hover и pointer показывают, может ли человек навести курсор и насколько точно он попадает в элемент. web.dev прямо предупреждает: разработчики не могут предполагать, что каждое крупное устройство — компьютер с мышью, а каждое маленькое — сенсорный экран. Ноутбук с сенсорным экраном и планшет с клавиатурой давно стали обычным делом. Меню, которое раскрывается только при наведении курсора, на таких устройствах просто не откроется.

Ширина экрана не говорит, чем человек управляет сайтом: пальцем, мышью или стилусом. Для этого у медиа-запросов есть отдельные признаки.

Как выбрать точки перелома?

Точки перелома, или брейкпоинты, — значения ширины, на которых макет перестраивается. Подбирать их по популярным моделям телефонов бессмысленно: web.dev советует не ставить их по классам устройств, продуктам, брендам и операционным системам, а позволить содержимому решать, где менять макет. Модели выходят каждый год, а правило «вёрстка ломается — ставим точку» работает всегда.

Порядок работы такой. Сначала страницу верстают под узкий экран — этот подход называют mobile first. Потом окно браузера постепенно расширяют и смотрят, где блоки начинают выглядеть плохо: строка текста растягивается, карточка становится слишком широкой, между элементами появляются пустоты. Там и ставят точку перелома. Справка web.dev формулирует это так: начинайте с небольших пороговых значений и постепенно увеличивайте их.

Для текста есть понятный ориентир. Классическая теория читабельности считает идеальной колонку в 70–80 символов в строке. Если абзац на широком экране выходит длиннее, пора ограничить ширину текстового блока или добавить точку перелома.

Мнение. Если подрядчик показывает адаптив «под iPhone и Samsung», попросите открыть страницу в браузере на компьютере и медленно сузить окно от полной ширины до минимума. Хорошая вёрстка не ломается ни на одной промежуточной ширине, а не только на трёх выбранных.

Что адаптировать, кроме ширины колонок

Перестроенная сетка — только половина адаптива. На телефоне человек управляет сайтом пальцем, часто держит его одной рукой и читает на ходу. Поэтому под маленький экран переделывают и кнопки, и шрифт, и формы, и всё, что прилипает к краю экрана. Вот что проверяют в первую очередь:

• Области касания — web.dev рекомендует делать кнопки и ссылки не меньше 48 пикселей, это примерно 9 мм, размер подушечки пальца. Между соседними целями оставляют около 8 пикселей, чтобы палец не задел соседнюю.
• Размер текста — Яндекс требует, чтобы весь текст удобно читался на экране мобильного устройства. Если читать можно только с увеличением, вёрстка не адаптирована, даже когда колонки перестроились.
• Таблицы — широкая таблица не должна растягивать страницу. Её прокручивают внутри своего блока или на узком экране превращают в карточки.
• Формы — у каждого поля свой тип: для телефона открывается цифровая клавиатура, для почты — клавиатура со значком @. Подписи ставят над полем, иначе на узком экране поле сжимается до нескольких символов.
• Меню и закреплённые элементы — длинное меню сворачивают, а закреплённую шапку, баннер о cookie и кнопку чата подбирают так, чтобы вместе они не закрывали текст.
• Изображения под экран — телефону не нужна картинка шириной в монитор. Атрибуты srcset и sizes дают браузеру выбрать файл подходящего размера.

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

Как проверить адаптивную вёрстку?

Адаптивную вёрстку проверяют в три приёма: эмуляцией в браузере, инструментом Яндекс Вебмастера и на живом телефоне. Друг друга они не заменяют. Эмулятор быстро показывает перестройку на любой ширине, Вебмастер сообщает, что увидел поисковый робот, а телефон — как страницей на самом деле пользуется человек.

Факт. По требованиям Яндекса страница должна открываться корректно и без горизонтальной прокрутки на устройствах с разрешением 320 пикселей и более.

Подробный список того, что смотреть на телефоне перед запуском, — в чек-листе что проверить в мобильной версии сайта.

Когда адаптивной вёрстки недостаточно

Адаптивная вёрстка решает задачу «тот же сайт, удобно на любом экране». Она не подходит, когда телефону нужен другой продукт: личный кабинет со сложными таблицами, редактор документов, сервис, которым пользуются в поле одной рукой. В таких случаях честнее сделать отдельный мобильный интерфейс или приложение, чем ужимать всё в одну сетку.

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

Во всех остальных случаях адаптив — вариант по умолчанию, и для информационного сайта, и для каталога, и для лендинга. Если хотите понять, сколько работы потребует ваш сайт, посмотрите, как мы делаем адаптивные сайты, и оставьте заявку: начнём с проверки текущей вёрстки на реальных устройствах.

Источники

• Рекомендации по индексированию с приоритетом мобильного контента — Центр Google Поиска
• Сайты для мобильных устройств — Справка Яндекс Вебмастера
• Основы адаптивного веб-дизайна — web.dev
• Доступные цели касания — web.dev
• Имитация мобильных устройств в режиме устройства — Chrome DevTools