En Service Art Rendering, la ventaja que tiene es que si tú le das aquí al botón derecho,
tú tienes una cadena de texto.
Que si yo aquí busco viviendas, ves, pues aquí tienes tus enlaces y tienes todo esto.
Pero vamos a crear en un momento una aplicación con Vite y vas a ver la diferencia.
Os enseño el código y ahora os explico bien eso, porque no es exactamente que no salga, ¿vale?
De hecho, Google dice, sí que lo puede ver, Google, Crawling...
Yo hice una precarga de la página en Service Art Rendering y luego ya en el cliente se cargaban los datos para cargar los tags de SEO.
Ese puede ser un tema, el hecho de que tú crees el Client Art Rendering, pero desde el servidor hagas cierto renderizado
y de hecho hay servicios como Pre-Rendering.
Lo que haces es renderizar tu aplicación Client Art Rendering y esta versión se la da a los crawlers.
Pues aquí tendríamos todos los beneficios que nos da.
A ver los beneficios.
Para el SEO, Bigger Crawl Budget.
Esto es lo súper mega importante.
¿Qué quiere decir esto de budget?
¿Cómo funciona el crawler de Google?
Dice, voy a ir a ver el blog de Midudev.
¿Cuánto tiempo tengo para dedicarle a la página de Midudev?
Cinco minutos, porque tengo mucho trabajo.
Tengo que crawlear millones y millones y millones de páginas.
Bueno, pues coge el crawler y dice, mira, un enlace.
Pum, entro.
Y empieza a abrir páginas.
¿Dónde va esta página?
Qué interesante.
Y en cinco minutos se pone esto a crawlear.
Obviamente, lo que está viendo no es esto, sino lo que lo está viendo es a través de esto.
Y está leyendo estos enlaces de aquí.
Y esta es la información que va leyendo todo este texto.
Ya está.
Cinco minutos.
He hecho lo que he podido.
Cada página tiene su importancia.
Cuanto más importante es tu página, más tiempo Google le va a dedicar.
Y eso es el budget.
Entonces, cuando dice Bigger Crawl Budget, lo que quiere decir es que Googlebot tiene un tiempo dedicado a tu página.
Cuanto más rápida sea capaz de leer tu página, más páginas verá.
Entonces, si tú tienes millones de páginas, por ejemplo, pues tienes una búsqueda con filtros y lo que sea.
Y tú dices, no, he creado un sitemap súper genial, esto lo que hace es una red de páginas, que tengo millones de páginas.
Da igual, porque Googlebot tiene un tiempo limitado.
Por lo tanto, tienes que hacer que sea lo más rápido posible tu página.
Si lo que estás haciendo es un client-side rendering, ¿qué pasa?
Que entras aquí y tú dices, mira, está en mi página Google.
Y dices, vale, sí, voy a ver.
Y se encuentra con esto.
Entonces, Google lo que hace es dejar esta página a una cola secundaria.
Lo que hace más tarde es ejecutar el JavaScript para entender la página, que es un client-side rendering,
y ver realmente qué es lo que es la página.
Pero, ¿qué pasa?
Que cuánto tiempo está tardando.
Tiene que levantar el navegador, ejecutar el JavaScript.
Entonces, lo que estás haciendo es que esos cinco minutos, si tu página es client-side rendering,
a lo mejor solo le da tiempo a mirar cinco páginas.
Cuando, en el otro caso, le puede dar tiempo a mirar cinco mil páginas.
Esto no es que lo diga yo, es que lo tienes aquí.
¿Cómo procesa el robot de Google el código JavaScript?
Te dice, mira, son tres fases.
Rastreo, renderizado, indexación.
El rastreo es el primero, que es el que te digo, el código fuente y rastrearlo.
Y luego hace el renderizado.
Pero fíjate, si miramos aquí cómo hace cada cosa.
Procesamiento, índice, no sé qué, cola de rastreo.
Las URLs van a cola de rastreo, la URL al rastreador, HTML se procesa,
van a cola de procesamiento, procesador.
Y esto, HTML procesado, procesamiento, esto es así.
Es como un loop todo el rato aquí.
En este procesamiento es aquí donde ocurren estas dos cosas.
El rastreo y el renderizado.
El primer procesamiento que hace es el más básico.
Y el más básico es tener el HTML aquí.
El JavaScript tiene un coste.
Sí que es verdad que ejecuta JavaScript, pero que ejecute JavaScript no significa que sea la mejor opción.
Le cuesta tiempo.
Y cuanto más tiempo, menos rastreas.
Esa es una de las grandes ventajas, ¿vale?
Por si me preguntas.
Esa es una.
Luego ves, tienes Bigger Crawl Budget, porque el budget es el tiempo que tiene Google para dedicarla a tu página.
Luego Faster Indexation, porque cuanto más rápido sea capaz de leer ese contenido, más fácil será que se indexe.
Tiene más ventajas.
Este sería No More Missing Content.
Es un poco lo que os digo, ¿no?
Que puede llegar el momento que Google dé por perdidas algunas páginas, porque nunca les da tiempo a renderizarlas.
Y esta es otra que es más de performance.
Mejores tiempos de respuesta.
No es lo mismo que nada más entrar tengas todo el HTML formado que te lo está devolviendo el servidor, que si tienes que ejecutar el JavaScript.
Nada más cargar la página es en blanco.
Es así de claro.
Autocasa es una de las páginas de mi empresa y tenemos Serversal Rendering.
Si yo refresco, no se ve perfecta, ¿vale?
Es normal, no lo carga todo.
No todo funciona perfecto.
¿Por qué?
Porque aquí hay unos inmuebles que los carga en el cliente porque no son importantes, pero tiene un montón de enlaces que puede seguir.
El blog, el compra tu hipoteca.
Todos estos enlaces.
Hay un montón de enlaces que sí que los puede seguir.
Al menos, de alguna forma, está dándole algo a Google, al usuario.
El primer renderizado que ve el usuario es esto.
No es una página en blanco.
El usuario no tiene que esperar a que se descargue el JavaScript, se evalúe el JavaScript, se ejecute el JavaScript, se descargue más JavaScript y se vuelve a ejecutar el JavaScript.
Hay que intentar optimizar también el tiempo.
Bueno, al menos te traigo los tres primeros y visualmente tú no te vas a dar cuenta de los que faltan.
Pero esto es una ventaja.
El pre-render te puede servir para páginas que no cambian mucho.
El pre-render ocurre una vez cada X tiempo y, por lo tanto, ese contenido se puede invalidar demasiado rápido.
Eso es una cosa que Next.js, por ejemplo, hace, ¿no?
Que te va generando el HTML para los static con incremental static regeneration, que es bastante interesante.
Pero hay veces que, claro, hay que tener cuidado porque a lo mejor es una página que constantemente cambia y tienes que ver si te sale a cuenta o no te sale a cuenta.
El server-side rendering tiene la ventaja de que es más inmediato la información que tiene.
El pre-render puede ocurrir cada X tiempo y suele ser más caro porque, ¿ves? Es un servicio que es aparte.
Claro, piensa que esto lo que hace es crear un navegador.
Mira, 250 páginas, 0 dólares.
Pero 250 páginas.
250 páginas en páginas, en webs, en condiciones.
Mira, necesito mis páginas cacheadas 7 días.
Claro.
Fíjate, cuanto menos tiempo, ¿ves?
Necesito mis páginas cacheadas cada 7 días.
Pues son 15 dólares, 20.000 páginas.
Pero si lo pones cada día, o sea, es raro, ¿no?
Es como que quiero menos caché.
Cuanta menos caché, más cuesta.
Porque, claro, más fresca es la información, más veces tienes que hacer el pre-render.
Y fíjate que no acepta menos de un día.
Entonces, el pre-render a lo mejor no es interesante para ciertas aplicaciones.
Mi blog es lo que se le llama como Jamstack.
Lo que hace es que antes de subirse, genera todos los estáticos HTML compilándolos con la fuente de información,
en mi caso, unos markdowns, y genera todos los HTML.
Yo cada vez que deployo, se generan todos los HTML.
Esto no es service-al rendering, es como toda la vida, un HTML.
Solo que estoy generando HTML de forma programática.
¿Cuál es la diferencia entre ...
Uno ...
Gracias por ver el video.