3D на живом сайте: наш эксперимент с three.js и что увидел Google

В октябре мы осознанно поставили туннель на three.js на первый экран собственного сайта, того, который приносит нам заявки. Через несколько дней мобильный PageSpeed показал 32, а средняя позиция в Search Console просела примерно с 10 до 17. Рассказываем, зачем мы проверяли это на живом трафике, что нашли и что изменили, не отказываясь от 3D.

КОРОТКО

Вредит ли 3D поисковой оптимизации?

Само по себе 3D поиску не вредит. Вредит, когда текст живёт внутри холста, когда тяжёлая часть грузится на любое устройство, даже если оно не может её нарисовать, и когда на ней ломаются тестовые браузеры. Google читает HTML, который отдаёт страница, а скорость оценивает по опыту реальных посетителей, а не по лабораторной оценке.

16 октября 2026 года первый экран peretz.agency стал сценой на three.js: туннель, в котором плывут наши проекты. Мы сделали это сознательно, на сайте с живым поисковым трафиком. Первые дни всё выглядело неплохо. Повторная проверка через несколько дней показала 32 из 100 в мобильном PageSpeed и 16 секунд заблокированного основного потока, а средняя позиция сайта в Search Console за неделю ухудшилась примерно с 10 до 17. К 27 октября, после нескольких небольших правок, та же страница, с тем же 3D для всех, у кого в устройстве есть видеокарта, показывает 78 на телефоне и 96 на компьютере.

Текст и есть страница. 3D только свет на ней.

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

ЭКСПЕРИМЕНТ

Почему на своём сайте, а не на пет-проекте

Новый подход к сайту можно обкатать на демо-стенде или пет-проекте, и многие так и делают. Только у пет-проекта нет того, ради чего такую проверку вообще стоит проводить: поискового трафика, истории в Search Console, посетителей со старыми телефонами и офисными ноутбуками и людей, которые открывают PageSpeed, прежде чем нам написать. На стенде 3D почти всегда выглядит прекрасно, потому что смотрит на него одна команда, и на хорошем железе.

Поэтому мы поставили three.js на собственный рабочий сайт и заранее договорились о правилах. Следим за PageSpeed и Search Console с первых дней. Если цифры проседают, ищем причину и чиним по ходу, а не откатываем всё при первой плохой оценке. И рассказываем о найденном, включая неприятное.

Пет-проект не покажет, как поведёт себя сайт с трафиком.

Риск был осознанный, и он был наш. Если бы что-то пошло не так, пострадали бы наши позиции и наши заявки, а не клиентские. Зато теперь, когда нас спрашивают, можно ли сделать сайт с 3D и не потерять поиск, мы отвечаем по собственным данным, а не по документации и чужим кейсам.

САЙТ

Что мы построили

3D у нас не один эффект на главной. За две недели оно разошлось по всему сайту:

• Главная: первый экран это туннель из наших проектов на three.js, с 3D-моделью автомобиля и эмбиент-музыкой.
• Футер: небольшие 3D-объекты на каждой странице, каждый в своём маленьком холсте на своём месте, без общего холста поверх всей страницы.
• Портфолио: 3D-мозаика всех проектов во всю ширину экрана, которую можно таскать.
• Контакты: маленькая диорама Сиэтла с горой Рейнир, Спейс-Нидл, косатками и паромом.
• Вакансии: игрушечная ракета, которая взлетает из футера, когда читатель до него доходит.
• 404: цифры сделаны лакированными 3D-фигурами, их можно крутить.

Всё это работает на одной общей копии three.js, подключённой один раз на весь сайт. И всё это оформление. Каждый заголовок, абзац, ссылка и цена остаются обычным HTML, который сервер отдаёт до запуска любого скрипта.

СИГНАЛ

Что показали PageSpeed и Search Console

PageSpeed Insights запускает Lighthouse в дата-центре Google. Для мобильного теста он изображает телефон среднего уровня: замедленную сеть и замедленный процессор. Чего у него нет, так это видеокарты. WebGL там всё равно работает, но Chrome рисует его программно, на процессоре, через рендерер SwiftShader.

Для сцены на three.js это худший случай. Работа, которую телефон отдаёт графическому чипу и делает за несколько миллисекунд, ложится на и без того замедленный процессор. Lighthouse насчитал 16 секунд Total Blocking Time, то есть времени, когда страница не могла ответить на касание. Оценка пошла следом.

Посетитель с современным телефоном этих 16 секунд не видел. Но мы не стали списывать 32 на особенности лаборатории, по двум причинам. Слабые телефоны и офисные ноутбуки без настоящего графического чипа существуют, и их владельцы получают ровно этот программный путь. А клиенты, партнёры и конкуренты тоже открывают PageSpeed. Студия, которая продаёт сайты, не может ответить им «у меня на телефоне всё нормально».

В те же дни просели позиции: средняя позиция сайта в Search Console за неделю ухудшилась примерно с 10 до 17. Клики и показы за те же четыре недели при этом выросли, но это заслуга не 3D: всё это время мы продолжали публиковать новые статьи и страницы услуг. И это важная деталь. Средняя позиция считается по всем запросам, где сайт появился, поэтому она ухудшается и когда страницы теряют места, и когда сайт начинает показываться по новым запросам ниже первой страницы. Такую цифру нужно разбирать по страницам и датам, до и после запуска, а не судить по одному числу.

Связать просадку с 3D напрямую мы не можем напрямую мы не можем: полевые данные Core Web Vitals копятся 28 дней, а за те же дни на сайте поменялось сразу многое. Поэтому мы отнеслись к ней как к раннему сигналу, без паники и без отката: на сайте что-то изменилось, и разбираться нужно сейчас, а не через месяц, когда придут полевые данные. Ради такого сигнала эксперимент и ставился на живом сайте.

ЛАБОРАТОРИЯ И ПОЛЕ

Что на самом деле измеряет Google

Данные о скорости бывают двух видов, и их легко перепутать.

Лабораторные данные это один тестовый прогон в контролируемых условиях. Lighthouse, оценка PageSpeed и отчёт в Chrome DevTools относятся к ним. Они воспроизводимы и хороши для поиска проблем.

Полевые данные это то, что реальные пользователи Chrome получили на странице за последние 28 дней, собранное в Chrome UX Report (CrUX). Именно их показывает отчёт Core Web Vitals в Search Console, и именно о них Google говорит, что хорошие Core Web Vitals совпадают с тем, что стремятся поощрять его основные системы ранжирования. Каждый показатель оценивается по 75-му процентилю визитов:

Цифра наверху отчёта PageSpeed в этот список не входит. Лабораторные 32 напрямую позиции не двигают. Но то, что они предсказывают, вполне реально: если в лаборатории основной поток заблокирован, самые слабые реальные устройства почувствуют это в INP, а именно они и составляют худшую четверть визитов.

Второе, что измеряет Google, это содержание. Google Search отрисовывает страницы в актуальном headless Chromium и потом читает получившийся HTML. Текст, нарисованный внутри холста, для него пиксели, а не слова. Поэтому каждое слово на наших 3D-экранах это HTML поверх сцены, начиная с единственного H1 на странице. Как отрисовка, скорость и содержание складываются в поиске сегодня, мы разбирали в статье SEO, AEO и GEO в 2026 году.

Лабораторная оценка это симптом. Полевые данные это диагноз.

СБОИ

Когда тест не мог даже закончиться

Прежде чем улучшать оценку, её нужно было получить. Какое-то время PageSpeed на каждой странице сайта, а не только на главной, отвечал «Browser tab has unexpectedly crashed».

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

Service worker. Сайт работает как PWA: service worker кэширует страницы для офлайна и принимает push-уведомления. Регистрировался он сразу при загрузке страницы. Наш хостинг отклоняет запросы с user agent HeadlessChrome, которым пользуются тестовые инструменты, а скрипт воркера запрашивается именно с ним. Регистрация при загрузке в такой ситуации роняла вкладку теста. Теперь воркер регистрируется при первом касании, клике или нажатии клавиши, а при загрузке только если страницей уже управляет воркер. Люди разницы не замечают; тестовый браузер, который страницу не трогает, его не запускает.

Холсты высотой со страницу. Наши сцены подстраиваются под размер экрана. Некоторые тестовые браузеры, в том числе Lighthouse, когда снимает полный скриншот, растягивают окно на всю высоту страницы. Холст, привязанный к высоте окна, превращается тогда в 3D-поверхность высотой 16 000 пикселей на главной и 10 240 в портфолио. Теперь у каждого такого холста есть максимальная высота: 2 200 пикселей для сцены на главной, это выше любого реального экрана, и 980 пикселей для мозаики портфолио на телефонах.

Тестовый браузер не посетитель, но дойти до конца он должен.

После этих двух правок PageSpeed снова заработал. Главная получила свои 32 честно.

ПРОВЕРКА ВИДЕОКАРТЫ

3D только там, где его рисует графический чип

32 пришли от программного WebGL. Поэтому очевидным шагом было не облегчать сцену для всех, а перестать отправлять её туда, где её некому нарисовать.

Сразу после разметки первого экрана, до того как браузер что-либо нарисует, короткий встроенный скрипт задаёт устройству три вопроса:

• Может ли оно вообще рисовать WebGL без серьёзной потери скорости? Скрипт запрашивает контекст с флагом failIfMajorPerformanceCaveat, который велит браузеру отказать, а не переключаться на что-то медленное.
• Кто рисует? Имя рендерера. SwiftShader, llvmpipe и другие программные рендереры значат, что графического чипа за работой нет.
• Просит ли посетитель меньше движения? Системная настройка prefers-reduced-motion.

Если хоть один ответ не тот, первый экран получает светлую версию: тот же заголовок, тот же текст и ссылки в классическом светлом виде сайта, а three.js вообще не скачивается. Если все ответы правильные, тот же скрипт добавляет предзагрузку three.js и саму сцену. Статических тегов script для них на странице нет.

Проверка не бесплатна. На машине без видеокарты любой вопрос к GPU стоит около 0,4 секунды, пока Chrome запускает программный рендерер. Мы это принимаем, потому что альтернатива это многие секунды сцены, которую устройство нарисовать не может. Мы пробовали спрашивать вместо этого WebGPU. Он отвечает только после первой отрисовки, так что страница сначала показывала одну версию, а потом переключалась на другую, и Lighthouse намерил сдвиг вёрстки 1, в десять раз выше нормы. От этого варианта мы отказались.

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

В локальном прогоне Lighthouse с программной графикой главная выросла с 32 до значений от 72 до 76 в разных прогонах, а Total Blocking Time упал с 16 секунд до нуля.

НЕ КЛОАКИНГ

Один HTML для всех

Показывать разным посетителям разное звучит близко к клоакингу, а клоакинг нарушает правила Google о спаме. Разница в том, на чём основано решение.

Клоакинг значит показывать поисковикам и людям разное содержимое, чтобы повлиять на ранжирование, обычно проверяя, кто спрашивает: user agent или IP-адрес краулера.

Наш сервер отдаёт один и тот же HTML всем: Googlebot, PageSpeed, iPhone, офисному компьютеру. Выбор происходит позже, в браузере, и зависит только от того, что умеет устройство. Человек с ноутбуком без графического чипа видит ту же светлую версию, что и тестовый браузер без него. Краулер, у браузера которого есть настоящий графический чип, получает сцену, без него получает светлую версию, точно как человек. Заголовок, текст и все ссылки в обеих версиях одинаковые.

Решайте по тому, что умеет устройство, а не по тому, кто спрашивает.

ПОЗЖЕ

Всё остальное ждёт своего повода

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

• Звук: аудиограф для эмбиент-музыки раньше собирался при загрузке и стоил около 0,3 секунды. Теперь он собирается при первом касании, клике или нажатии клавиши. Визит, где музыка уже играет, подхватывает её на следующей странице сразу.
• 3D в футере: его скрипт стартует, когда до футера остаётся около 800 пикселей (350 на телефонах) и у браузера есть свободная минута. Каждый объект рисуется в своём маленьком холсте, так что полноэкранного 3D-слоя поверх текста нет никогда.
• Контакты: диорама Сиэтла скачивается после загрузки страницы, в момент простоя браузера.
• Вакансии: three.js для ракеты запрашивается, когда до футера остаётся около 900 пикселей: достаточно рано, чтобы успеть, и достаточно поздно, чтобы не мешать странице.
• Посетители, которые просят меньше движения, ракету не получают вовсе, а на главной видят светлый первый экран.

СДВИГИ ВЁРСТКИ

Страницу двигало не 3D

Когда 3D было под контролем, оставшиеся проблемы с Core Web Vitals обнаружились совсем в другом месте: в обычных блоках, которые скрипты строили после первой отрисовки.

• Оглавление статьи на телефонах. Скрипт собирал его из заголовков уже после того, как появился текст, и сдвигал текст вниз. Теперь то же оглавление рисует сервер прямо в HTML, а скрипт только подхватывает его. CLS на страницах статей упал с 0,19 до 0.
• Полоса разделов блога. Она решает, помещаются ли разделы в одну строку или раскрываются в две колонки. Пока это решение принимал скрипт после отрисовки, страница прыгала: CLS 0,5. Теперь несколько строк сразу после полосы решают это до первой отрисовки. CLS 0.

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

ЧЕК-ЛИСТ

Перед запуском 3D-сайта

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

• Весь текст, заголовки и ссылки сделаны в HTML, вне холста, и есть в исходном коде страницы до запуска скриптов.
• Один H1, настоящий текст, а не часть картинки или сцены.
• Сцена грузится только там, где её нарисует графический чип, решение принимается до первой отрисовки, для всех остальных и для режима «меньше движения» есть светлая версия.
• Один и тот же HTML для каждого посетителя и каждого бота. Решение в браузере по возможностям устройства, никогда на сервере по user agent.
• У каждого холста, привязанного к высоте окна, есть максимальная высота.
• При загрузке не запускается ничего, на чём спотыкаются тестовые браузеры: service workers, звук, тяжёлые наблюдатели. Запускайте их при первом действии посетителя.
• Второстепенные сцены грузятся рядом со своим местом на странице или в момент простоя, никогда все сразу.
• Вёрстка зафиксирована до первой отрисовки: блоки, которые строят скрипты, получают разметку или размер от сервера.
• Запуск на живом сайте с планом наблюдения: PageSpeed и Search Console с первых дней, и готовность чинить по ходу, без отката при первой плохой цифре.
• Лабораторные тесты для поиска проблем, полевые данные раз в месяц: PageSpeed находит проблемы, отчёт Core Web Vitals в Search Console показывает то, что видит Google. Мы смотрим и то, и другое в рамках продвижения сайтов.

РЕЗУЛЬТАТ

Где мы сейчас

Цифры PageSpeed от 27 октября 2026 года; лабораторные результаты гуляют на несколько пунктов от прогона к прогону. 3D по-прежнему на месте для всех, чьё устройство может его нарисовать, музыка по-прежнему играет, а ракета по-прежнему взлетает на странице вакансий.

Чего у нас пока нет, так это длинной полевой истории после изменений: CrUX собирает 28 дней реальных визитов, так что полная картина в Search Console, включая то, вернётся ли средняя позиция с 17 к прежним 10, появится позже. Мы добавим её в эту статью, когда она будет, какой бы она ни оказалась.

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

FAQ

Источники

• Google Search Central: Understand the JavaScript SEO basics
• Google Search Central: Understanding Core Web Vitals and Google search results
• Google Search Central: Understanding page experience in Google Search results
• Google Search Central: Spam policies for Google web search (cloaking)
• web.dev: Why lab and field data can be different
• Chrome for Developers: Chrome UX Report
• Chrome for Developers: Lighthouse performance scoring
• Lighthouse: Network and CPU throttling
• MDN: WEBGL_debug_renderer_info
• MDN: HTMLCanvasElement.getContext() and failIfMajorPerformanceCaveat
• MDN: prefers-reduced-motion