Cargando
Demos en vivo

¿Una web 3D va más lenta o perjudica el SEO? Lo que importa y lo que no

La respuesta corta: el 3D puede hacer más lenta una página y puede esconderle textos a Google, pero ninguna de las dos cosas es obligatoria. Google lee texto, no lo que se dibuja en una escena 3D, y mide cómo va una página para la gente de verdad con tres cifras, las Core Web Vitals. Una web 3D que mantiene sus textos en HTML y su peso a raya puede salir bien parada en las dos cosas.

Esto es para quien duda entre una web 3D y una normal. Explica qué mide Google y cuánto cuenta, dónde suele salir caro el 3D y qué hacen los kits de Promti al respecto, con cifras de la build de esta misma web y no con promesas de velocidad.

El trabajo que hay detrás de una página 3D en conjunto —el modelo, el scroll, el móvil, la página legal— está en cómo se hace una web 3D.

Qué mide Google y cuánto cuenta

web.dev, la web de Google para desarrolladores, define tres Core Web Vitals. Largest Contentful Paint (LCP) es lo que tarda en aparecer el contenido principal: bien es 2,5 segundos o menos, mal, más de 4. Interaction to Next Paint (INP) es lo que tarda la página en responder a un clic, un toque o una tecla: bien son 200 milisegundos o menos, mal, más de 500. Cumulative Layout Shift (CLS) mide cuánto se mueven las cosas mientras carga: bien es 0,1 o menos, mal, más de 0,25.

Se juzgan con visitas reales, en el percentil 75, por separado en móvil y en ordenador: una página aprueba cuando al menos tres de cada cuatro visitas salen bien en las tres. Esas visitas salen del Chrome UX Report, que solo recoge páginas y webs con visitantes suficientes para que el dato signifique algo. Una web pequeña y nueva puede no tener ningún dato, y el informe de Core Web Vitals de Search Console se limitará a decir que no hay bastantes.

¿Y cuánto pesan? La página de Google sobre la experiencia en la página dice que sus sistemas de clasificación usan las Core Web Vitals, pero que sacar buenos resultados no garantiza estar arriba, y que Google siempre intenta mostrar el contenido más relevante aunque su experiencia sea floja. La velocidad desempata entre páginas útiles; no sustituye a ser la página útil.

Dónde puede perder una página 3D

El peso. Todo lo que necesita una escena tiene que descargarse antes de poder dibujarse: librería, código, modelos, texturas, fotos. Como referencia, el Web Almanac 2025 de HTTP Archive situó la portada mediana en 2,6 MB en el móvil y 2,9 MB en el ordenador en julio de 2025, y en sus datos de campo aprobaban las tres Core Web Vitals el 57 % de las portadas móviles de menos de 1 MB, frente al 30 % de las de 5 MB o más.

El trabajo del hilo principal. El INP empeora cuando hay tareas largas que tienen ocupado al navegador —web.dev llama larga a cualquier tarea de más de 50 milisegundos—, y cargar, analizar y ejecutar un script grande es justo el tipo de trabajo que menciona. Una librería 3D es un script grande.

Los textos dentro de la escena. La guía de Google para desarrolladores es clara: lo que se muestra en un canvas no se indexa. Su guía de problemas con JavaScript pone WebGL como ejemplo de algo que Googlebot no admite. Un título que solo existe dentro del 3D, para el buscador, no está. Google tampoco hace scroll ni clics en la página, así que un texto que solo llega tras una interacción puede no verse nunca.

El móvil. Google indexa y clasifica la versión móvil de las páginas, y es en el móvil donde se nota el peso de una escena: el manual de three.js recuerda que la pantalla de un móvil puede tener tres píxeles por cada uno de diseño, es decir, nueve veces los píxeles que dibujar.

Qué hacen los kits al respecto

El texto, primero, para el buscador. Los buscadores y los lectores de pantalla toman las palabras de los kits del HTML: títulos, párrafos, precios, botones, todos colocados sobre la escena en vez de pintados dentro. La frase grande de Product, que también se dibuja en 3D, se repite en el HTML, y cada foto de Forest lleva una descripción escrita. El .zip incluye además el título, la descripción, las etiquetas para compartir, robots.txt, el idioma de la página y, con tu dominio, un sitemap y la dirección canónica.

Un peso conocido. La build de esta web del 27 de septiembre de 2026 mide three.js —la única librería detrás de los cuatro kits— en 142 KB comprimida, con el código propio de cada escena en un archivo aparte que se carga después del primer script. Entre 19 y 27 archivos, de 1,1 a 3,7 MB sin contar las tipografías, forman la descarga de un kit, y el grueso son las imágenes o el modelo de la demo, que se cambian por los tuyos. El asistente reduce las fotos e imágenes demasiado grandes antes de meterlas, y rechaza los modelos de más de 25 MB.

Menos píxeles de los que admitiría la pantalla. Por densa que sea, ningún kit dibuja a más de 1,75 veces la resolución del diseño; en el móvil, Forest se queda en 1,5 y baja de cuarto en cuarto si sus fotogramas van lentos. Una pestaña oculta no dibuja nada.

Segundas visitas más ligeras. Los scripts y las tipografías viajan con cabeceras que piden al navegador guardarlos un año, y Cloudflare Pages entrega los archivos desde su red. Sin WebGL, los textos y los botones siguen sirviendo, y Forest recurre a tus fotos, planas.

Cómo comprobar tu web

Primero, los datos de campo: cuando tu web tenga visitas suficientes, el informe de Core Web Vitals de Search Console agrupa sus páginas por estado, en móvil y en ordenador, con el mismo Chrome UX Report. Hasta entonces dirá que no hay datos, y en una web nueva eso es lo normal, no un suspenso.

Diga lo que diga el informe, lo que más se nota en una página 3D suele ser lo más sencillo: imágenes y modelos más ligeros, todos los textos importantes en el HTML y una escena que no dibuje más píxeles de los que necesita la pantalla.

Preguntas

¿Una web 3D es mala para el SEO?
No por sí misma. Perjudica cuando los textos solo viven en la escena, que Google no lee, o cuando la página pesa tanto que las visitas salen mal en las Core Web Vitals. Con los textos en HTML y el peso controlado, una página 3D se juzga como cualquier otra: primero por su relevancia, como dice Google.
¿Google ve lo que hay en una escena 3D?
No. Según Google, lo que se muestra en un canvas —que es donde dibuja WebGL— no se indexa, y Googlebot no admite WebGL. Lee el HTML que rodea la escena: títulos, textos, descripciones de imágenes, enlaces.
¿Qué son unas buenas Core Web Vitals?
Según web.dev: un Largest Contentful Paint de 2,5 segundos como mucho, un Interaction to Next Paint de 200 milisegundos o menos y un Cumulative Layout Shift de 0,1 o menos, cada uno en al menos el 75 % de las visitas reales, por separado en móvil y en ordenador.
¿Por qué Search Console no muestra Core Web Vitals de mi web?
Porque los datos salen de visitas reales con Chrome, y el Chrome UX Report solo incluye páginas y webs con las suficientes para que el dato sea estadísticamente válido; Google no publica el umbral. Una web nueva o pequeña a menudo no tiene ninguno, y no hay nada que arreglar.
¿Los kits de Promti aprueban las Core Web Vitals?
No publicamos una nota, porque las Core Web Vitals se miden con visitas reales a cada web, en los aparatos de sus visitantes, con sus propias fotos y su modelo. Lo que controla un kit es lo que se explica arriba: textos en HTML, peso contado, dibujo con tope, archivos en caché. Las demos en vivo están para probarlas en tu propio móvil.