Пустой HTML: почему современные сайты обманывают ожидания

Откройте любой популярный сайт. Кликните правой кнопкой мыши и выберите "Просмотр кода страницы". Что увидите? Не ту картинку, что на экране. А скудный скелет: пара meta-тегов, ссылка на CSS и вот это:

<div id="app"></div>

И всё. Настоящий контент — текст, данные, структура — подгружается потом. Через JavaScript, который браузер скачивает и запускает. Страница уже отрисована, а содержимое ещё летит с сервера.

Так было не всегда. Разобраться в этом важно, если вы занимаетесь веб-разработкой. Особенно если думаете о скорости, доступности и SEO.

Веб как документ: золотая эпоха

Изначально всё было просто. Браузер запрашивал документ. Сервер отдавал готовый HTML. Браузер показывал его. Всё, что видно, жило прямо в коде. Хотите понять страницу — смотрите исходник.

Это не минус, а плюс. Контент нёс смысл сам по себе. Дата в статье — не просто цифры, а часть текста с объяснением. Ссылка — с описанием, куда ведёт. Страница была самодостаточной. Исходник — это прозрачность на 100%.

Даже когда серверы научились генерировать HTML динамически (CGI, PHP), суть не менялась. Бэкенд, шаблоны, стили — всё сливалось в цельный документ перед отправкой пользователю.

AJAX: начало перемен

Потом появился XMLHttpRequest. Браузеры заговорили с сервером без перезагрузки. Обновляли куски страницы на лету. К середине 2000-х это назвали AJAX. Google Maps показал, как это работает: плавно, отзывчиво, как десктопное приложение.

Идея была крутая. Зачем перезагружать всю страницу ради одного блока? Зачем слать меню заново? AJAX решал реальные боли. Пользователи хотели динамики. Разрабы — давали её.

Но цена оказалась высокой.

Цена прогресса

К 2010-м сложился новый подход:

1. Отправляем минимум HTML — пустой контейнер.
2. Загружаем JS-приложение.
3. Тянем данные из API.
4. Заполняем интерфейс в браузере.

Фреймворки вроде React, Angular, Vue помогли. Они упростили управление состоянием, переиспользование компонентов, работу в команде. Без них сложные apps были бы адом.

Но веб изменился кардинально.

Что потеряли и зачем это важно

Исходник стал бесполезным.

HTML на странице — пустышка. Контент, который видит юзер, рождается в JS. Нет данных в коде — нет понимания без запуска скриптов.

Разрабам теперь приходится копаться в логике, API, состояниях. Прозрачность ушла.

Машины страдают ещё больше. Поисковики для SEO, скрейперы для AI, инструменты доступности — им приходится эмулировать браузер. Выполнять JS, кликать, ждать. Ресурсов уходит море, вместо простого чтения HTML.

SEO страдает: индексация замедляется. Доступность хромает: структура неясна без рендера. AI для обучения тратит время на headless-браузеры.

Корень проблемы глубже

Дело не в JS или фреймворках. Это смена мышления.

Старое: Страница = документ со смыслом внутри.
Новое: Страница = оболочка для интерфейса, смысл — снаружи.

Документы понятны сами по себе. Интерфейсы требуют исполнения. Мы выиграли в интерактивности, проиграли в читаемости.

Для Figma или Slack это оправдано — там нужен app. Но шаблон прилип кезде: даже блоги и лендинги лепят как SPA. Качели зашли слишком далеко.

Почему это важно для пользователей NameOcean

В NameOcean мы следим за такими трендами. Ваш domain и hosting должны подходить под задачу, а не навязывать сложность.

Для контент-сайтов, лендингов, текстовых страниц берите SSR или статическую генерацию. HTML несёт смысл сразу. SEO ловит контент мгновенно. Медленный интернет — и текст уже виден, без ожидания JS.

Для дашбордов, инструментов, коллаборации — клиентский рендер в самый раз. Главное — осознанный выбор, а не мода.

Взгляд в будущее

Веб найдёт баланс. Фреймворки уже предлагают гибриды: SSR для старта, клиентский JS для динамики, статика для константы.

Next.js, Svelte, Astro показывают: документ и app можно совместить.

Будьте в теме. Выбирайте архитектуру под нужды. Делайте сайты индексируемыми, доступными и прозрачными — вместе с богатством интерфейса.

Прозрачность и мощь — союзники, а не враги.