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