Мобильная вёрстка блога: что показал замер на 390 px в 81 статье нашего прода

Что показал замер 81 статьи на 390 px: 171 таблица и 11 блоков кода без прокрутки, раздутый вьюпорт, срез обложки. Как проверить и что правится админкой.

Коротко

• Материал актуален на 06.10.2026. Данные — по нашему собственному продакшену, срез сделан 06.10.2026 по живому дампу: 101 запись в базе, из них 81 статья, 112 URL в sitemap.xml.
• Горизонтальный скролл на телефоне — это не «широкая таблица», а сломанный вьюпорт всей страницы. Замер одной статьи до правки: clientW 390 · scrollW 722 · innerW 722. После правки: 390 / 390 / 390.
• Необёрнутых таблиц в корпусе 171 из 202 — они живут в 64 статьях из 81 (79 % по нашему расчёту). Необёрнутых блоков кода — 20 тегов <pre> в 11 статьях из 81; там нет ни одного обёрнутого.
• Причина почти всегда одна: у широкого содержимого нет контейнера с overflow-x:auto. Браузер не обрезает таблицу, а расширяет под неё документ.
• Для робота это важнее, чем для читателя: Google индексирует rendered HTML и прямо предупреждает, что не все боты исполняют JavaScript. Проверять надо curl'ом с User-Agent поискового робота, а не взглядом в браузере.

Как измеряют ширину страницы на телефоне?

Один скриншот ничего не доказывает: на снимке раздувание видно, а кто его вызвал — нет. Мы меряем три числа в одном замере.

• document.documentElement.clientWidth — сколько страница заняла по факту.
• document.documentElement.scrollWidth — насколько она шире экрана.
• window.innerWidth — какой вьюпорт отдал браузер, то есть какой он считает рабочим.

Замер делаем головным Chromium по DevTools-протоколу с эмуляцией 390 × 844, deviceScaleFactor 3, режим мобильного устройства. Три числа снимаются одновременно, потому что поломка выглядит по-разному: у блока может быть нормальная ширина, а документ при этом 722.

Норма у этого теста простая и своя для каждого сайта: docScrollW === clientW. Если ширина прокрутки больше ширины клиента — страница на телефоне скроллится целиком, и это всегда дефект вёрстки, а не «особенность дизайна».

Почему раздувается весь сайт, а не одна таблица?

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

Два характерных случая из нашего корпуса:

• Четырёхколоночная таблица без обёртки на экране 390 px даёт scrollWidth 579 — на 48 % шире экрана.
• Блок кода в <pre> без обёртки и с white-space:pre даёт layout-вьюпорт 722: вьюпорт, который браузер отдал, тоже стал 722 вместо запрошенных 390.

Дальше включается цепочка: документ шире экрана → position:fixed элементы считаются от раздутого документа → полоса прокрутки появляется под текстом, а не внутри блока. Читатель на телефоне свайпом двигает всю страницу и попутно сдвигает шапку. Именно поэтому починка «уменьшить шрифт» или «сделать колонки уже» не работает: размер элемента не является причиной, причиной является отсутствие точки прокрутки.

Сколько страниц в нашем корпусе ломаются на 390 px?

Все числа ниже — по нашему дампу и нашему скрипту, они воспроизводятся повторным прогоном. Соотношения — наше вычисление, а не внешняя норма.

Отдельная строка — связность. Статей с двумя и более входящими ссылками 61 (75 %), хотя бы одной входящей — 75 (93 %), полностью изолированных — 6. Считаем мы это не ради красивого отчёта: изолированная страница получает обход только из карты сайта, то есть индексируется медленнее остальных.

Что опаснее — таблицы или блоки кода?

Таблицы ломают чтение, код ломает вёрстку сильнее. Таблицу браузер ещё может сжать: у неё есть переносы, она режет колонки, в крайнем случае текст ляжет в две строки. У <pre> с white-space:pre такой возможности нет — каждая строка сохраняет длину.

Отсюда практический вывод: 171 необёрнутая таблица — это в основном неприятно, но поправимо самим читателем, а 20 необёрнутых блоков кода в 11 статьях — это гарантированно раздутый вьюпорт. Приоритет правки в нашем корпусе был обратный интуиции: сначала 11 статей с кодом как единичные тяжёлые дефекты, потом таблицы массово, при следующей вычитке.

Почему это важно для робота, а не только для читателя?

Документация Google по JavaScript-сайтам говорит прямо: «Keep in mind that server-side or pre-rendering is still a great idea because it makes your website faster for users and crawlers, and not all bots can run JavaScript». То есть пререндеринг полезен не только ради скорости — часть краулеров JavaScript не исполняет вовсе и видит только HTML ответа сервера.

Там же про индексацию: «If the content isn't visible in the rendered HTML, Google won't be able to index it». Для нас это означало методичку: проверять отдачу надо curl'ом с User-Agent поискового робота. Разница измерена на нашем же проде: серверный HTML страницы блога с ботовым UA весит 27–36 КБ и содержит текст статьи, а тот же адрес с обычным браузерным UA отдаёт оболочку приложения примерно 4 КБ.

Мобильная ширина сюда же: страница, у которой вьюпорт раздут до 722 px, формально индексируется, но на мобильной выдаче выглядит как брак. Пороги Core Web Vitals мы приводим как прочитанную норму, а не как свою оценку. LCP — не больше 2,5 с, INP — не больше 200 мс, CLS — не больше 0,1. Мерить их надо на 75-м персентиле загрузок, отдельно для мобильных и для десктопных устройств.

При чём тут обложка статьи?

При том, что второй по частоте мобильный дефект мы нашли не в теле, а в шапке статьи. Контейнер обложки задан как блок фиксированной высоты с обрезкой, а картинка внутри — с заполнением без ограничения ширины. Мерка вертикального среза по нашей разметке: 16,1 % на 1440 px, 19,8 % на 1600 px, 25,2 % на 1920 px.

Практический смысл: цифра или дата, поставленная на обложку близко к краю, на широком экране просто исчезает. Мы решили это геометрией, а не вёрсткой — безопасная полоса содержимого y 190…530 px. Все обложки, что мы делаем сейчас, проверяются до загрузки файла: контент должен попасть в полосу, иначе карточка не уходит на сайт.

Горизонтальный срез на 390 px по нашему замеру мал — около 4 %, поэтому обложка на телефоне жива. Пропадает ровно то, что нарисовано по вертикальным краям: подписи, выноски, даты.

Как чинить: что правится в админке, а что только в коде?

Грубая ошибка — отправить все 171 таблицу в ручную правку. Часть дефектов чинится одним правилом CSS, и это как раз наш случай.

Шаблон обёртки, который мы теперь пишем сразу в теле статьи, а не чиним постфактум:

<div style="overflow-x:auto;-webkit-overflow-scrolling:touch;
      margin:1.7em 0;padding-bottom:.4em">
  <table> … </table>
</div>

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

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

Как проверить свой сайт за один вечер?

Пять шагов, ни один не требует подрядчика и денег.

1. Открыть страницу в DevTools на ширине 390 px и в консоли прочитать document.documentElement.scrollWidth. Признак поломки — число больше 390.
2. Пройти по самым длинным таблицам и блокам кода: признак — горизонтальная полоса прокрутки появляется под текстом, а не внутри блока.
3. Запросить страницу с User-Agent робота и сравнить с браузерным ответом. Признак — текст статьи виден только в браузерном HTML.
4. Посмотреть обложку на 1440, 1600 и 1920 px. Признак — дата или цифра уползает за край кадра.
5. Посчитать по своим статьям три числа: доля с самодостаточным блоком «Коротко», доля с двумя и более входящими ссылками, доля без единой внешней ссылки. Признак — любая из трёх ниже половины.

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

Кто виноват на самом деле, если страница 722 px?

Самая дорогая ошибка в этом поиске — исправить не тот элемент. В нашем замере в список выходящих за вьюпорт попал пустой элемент с position:fixed: у него унаследованная ширина, то есть он был жертвой раздутого документа, а не причиной.

Поэтому мы ищем не по размеру элемента, а по признаку: скрипт печатает тройку clientW / scrollW / innerW и список узлов, выходящих за вьюпорт, отдельно отсекая служебный пререндерный блок. Так виновник находится за один прогон вместо ручной переборки половины DOM.

Сколько это стоит и где граница самопомощи?

Отдельной строки на «починку мобильной вёрстки» в прайсе у нас нет, и выдуманную цену приводить не будем. Граница проходит по признаку доступа: если правка живёт в тексте статьи — её делает редактор, если в CSS или в разметке страницы — нужен разработчик с репозиторием.

Что можно самому: обёртки таблиц, структура блоков, ссылки на первоисточники, геометрия новых обложек. Что нельзя: правила CSS для контейнера статей, канонические адреса, dateModified в разметке, поведение шапки при обрезке. Второй класс работ — это аудит с приоритетами и ТЗ, а не «наймите нас», потому что объём первой половины работы честно измеряется количеством статей в корпусе.

Что мы сделали со своим корпусом и что дальше?

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

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

Этот текст сам попал в собственный срез. После записи в прод страница на 390 px показала scrollWidth 436 — скрипт-гейт проверяет разметку, а не рендер, и inline-код в нумерованных списках он не ловит. Дальше была бинарная диагностика: по одному скрываем элементы и смотрим, где ширина падает. Нашли два источника — длинные URL в разделе «Источники» (436 → 413) и 18 необёрнутых inline-фрагментов <code> (413 → 390). Обе правки сделаны через админку, стили на месте, кода не трогали; контрольный замер на живом проде — 390 / 390 / 390. Вывод, который стоит держать в гейте: проверять надо не только файл перед записью, но и отдачу после неё.

Как это связано с поиском и заявками?

Мобильная вёрстка не приносит трафик сама по себе, она перестает его отнимать. Трафик приносят тексты, которые робот индексирует и которые нейроответ может процитировать: самодостаточный блок с фактами и датами, ссылка на первоисточник, связность внутри корпуса. Про то, чем задачи SEO и GEO реально отличаются, мы разбирали замеры на 76 страницах прода, а приёмку работ по измеримым критериям — в чек-листе из 24 пунктов.

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

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

Источники

• web.dev, «Web Vitals» — пороги LCP, INP, CLS и правило 75-го перцентиля: web.dev/articles/vitals, текст прочитан 06.10.2026.
• Google Search Central, «Crawl and index JavaScript» — про пререндеринг, rendered HTML и ботов, которые не исполняют JavaScript: developers.google.com/…/javascript-seo-basics, страница обновлена 04.03.2026, прочитана 06.10.2026.
• Числа по корпусу — дамп нашего прода и логи замеров 06.10.2026, методика описана в тексте, соотношения — наше вычисление.