Готовая страница оставалась за прелоадером
10 октября 2026 года мы изменили порядок показа страниц DDRW. Текст и основная ссылка теперь доступны без ожидания интерактивной части приложения. В нашем лабораторном прогоне главная была открыта для чтения к 2,29 секунды вместо 5,16. Это наблюдение о доступности содержимого, а не доказательство ускорения загрузки всех ресурсов.
Проблема обнаружилась при проверке мобильного сценария. Сервер уже передавал HTML с описанием услуг и ссылками, браузер загружал оформление, но поверх страницы оставался прелоадер. Его закрытие было связано с готовностью WASM — исполняемого модуля приложения. Посетитель продолжал смотреть на заставку, хотя полезная часть страницы уже существовала.
Для бизнеса такая зависимость неудобна: человеку нужно понять предложение и найти способ обратиться. Декоративная сцена и сложные обработчики могут загружаться отдельно. Мы сосредоточились на этой последовательности, сохранив оформление и интерактивные возможности сайта.
Что изменили в первом экране
Прелоадер теперь ожидает оформление страницы, а не WASM и 3D. На главной разместили текст и основное действие так, чтобы они помещались в первый экран: на компьютере модель находится рядом с предложением, на телефоне занимает компактную область над ним.
Основное действие сделали обычной ссылкой на контакты. До готовности интерактивного кода она переводит посетителя на страницу обращения. После загрузки приложения тот же элемент открывает форму обсуждения проекта. В результате медленная загрузка интерактивной части не оставляет человека с видимой, но неработающей основной кнопкой.
Это конкретный пример постепенного улучшения интерфейса: базовый путь доступен через HTML, дополнительные возможности подключаются позднее. Различие между серверным HTML и последующим подключением обработчиков объясняется в материале web.dev о рендеринге. Само наличие серверного HTML ещё не решает проблему, если готовый текст закрыт заставкой.
Как проводили сравнение
До и после публикации открывали главную и страницу «Сайты для бизнеса» в изолированных контекстах Chromium 153 без сохранённого кэша. Размер окна составлял 390×844. Процессор замедляли в четыре раза, скорость загрузки ограничивали до 2 Мбит/с, отдачи — до 750 Кбит/с, задержку сети — до 150 мс.
Это эмуляция на компьютере, а не измерение физического телефона. Для каждой страницы выполнен один холодный прогон на редакцию. Наблюдатель проверял исчезновение прелоадера после события load. Поэтому число показывает верхнюю границу: к этому моменту содержимое уже было доступно. Оно не определяет точную миллисекунду первого появления текста.
| Страница и наблюдение | До изменений | После изменений |
|---|---|---|
| Главная: прелоадер отсутствует к моменту проверки | 5,16 с | 2,29 с |
| Услуга: прелоадер отсутствует к моменту проверки | 4,98 с | 3,45 с |
| Главная: событие navigation load | 2,32 с | 2,26 с |
| Услуга: событие navigation load | 2,16 с | 3,42 с |
У страницы услуги во втором прогоне ожидание первого байта ответа, TTFB, выросло примерно с 0,15 до 1,16 секунды. Эта вариация влияет на итоговое время. Одного прогона недостаточно, чтобы вычислить устойчивое ускорение или отделить вклад изменения кода от колебаний сети.
Почему нельзя обещать «сайт стал быстрее вдвое»
По главной видно сокращение ожидания заставки, но полная загрузка почти не изменилась. На странице услуги событие load произошло позднее. Сжатый Brotli-модуль WASM увеличился с 677 563 до 686 240 байт: уменьшение веса приложения не было результатом этой работы.
Мы также не получили полевые Core Web Vitals и не измеряли INP, то есть отзывчивость во время реальных взаимодействий. Оценка Lighthouse в это сравнение не входила. web.dev отдельно объясняет различия лабораторных и пользовательских данных: условия отдельной проверки не описывают разнообразие устройств, сетей и действий посетителей.
Корректный вывод уже: убрана программная зависимость показа текста от готовности WASM. Это проверено отдельным сценарием с недоступным модулем, включая переход по основной ссылке. Процент роста заявок или продаж из этих данных получить нельзя.
Что сделали с декоративной 3D-сценой
Сфера перестаёт постоянно отрисовываться, когда уходит за пределы экрана или вкладка скрыта. При возврате отрисовка возобновляется. Плотность пикселей ограничена значением 2. Для настройки уменьшенного движения показывается статичный кадр, который обновляется при изменении темы и размера.
Эти изменения устраняют ненужную работу сцены в конкретных состояниях. Мы проверили остановку и возобновление вызовов WebGL. Расход батареи и температуру устройства отдельно не измеряли, поэтому количественных обещаний об экономии энергии здесь нет.
Как проверяли результат
Интерфейс проверен на ширинах 320, 390, 768, 1024 и 1440 пикселей в обеих темах. Проверки включали отсутствие горизонтального переполнения, доступность основных действий, работу без готового WASM и автоматическую проверку доступности. После публикации все 45 адресов sitemap ответили HTTP 200.
Для обращения предусмотрены события открытия формы, валидной попытки отправки, ошибки и подтверждённого принятия сервером. Проверка событий использовала подменённый API: она подтверждает логику интерфейса, а не получение настоящего письма клиентом. Чтобы оценить конверсию, нужны настроенные цели, реальные визиты и достаточный период наблюдения.
Если ваш сайт долго показывает заставку, начните с простого вопроса: что именно она ожидает? Затем отдельно проверьте чтение предложения, переход к обращению и готовность сложных функций. Такой разбор помогает согласовать предметную задачу по сопровождению сайта, не подменяя её красивой оценкой из одного теста.
