En este tutorial aprenderemos algunos conceptos básicos sobre qué es Server Side Rendering en Front, qué ventajas nos aporta con respecto al SEO y qué frameworks nos ofrecen esta posibilidad.
Índice de contenidos
1. El problema de las SPA con el SEO
Actualmente es muy común ver multitud de páginas web hechas siguiendo la estructura SPA (Single page application), pero esto presenta un problema a la hora de tratar con el SEO. Y es que al generarse el contenido de manera dinámica por JavaScript, los motores de búsqueda no pueden indexar las páginas.
Esto es porque en SPA lo que se renderiza es un único fichero HTML que actualiza su contenido dinámicamente (gracias a JavaScript). Eso no significa que hacer una SPA sea una mala idea; si tu página no depende del SEO, es una opción totalmente válida.
Pero, ¿y si el SEO sí es importante?
2. Alternativa a la SPA: SSR (Server Side Rendering)
SSR no es un concepto nuevo; existe en el backend desde hace más de veinte años. El más antiguo es Common Gateway Interface, aunque es más probable que si el ejemplo son los Java Servlets sea más fácil evocarlo. Los servlets de Java nos permiten realizar y generar peticiones http desde el backend, evitándole al front esta tarea para aliviarle la carga. La novedad es que esta práctica se ha podido traer al front de manera nativa, incluido en ciertos frameworks, lo que nos permite poder prescindir del backend (dependiendo del proyecto, claro. Si estamos gestionando un blog, puede ser buena idea, pero una aplicación más pesada siempre necesitará backend).
Aunque en este tutorial vamos a tratar SSR desde el front y desde NextJS, existen otros frameworks para realizar esta tarea. Gatsby es otra herramienta que facilita la creación de una aplicación SSR; e, incluso, puedes prescindir de un framework y hacerlo por tu propia mano. Pero aquí nos centraremos en NextJS.
Antes de todo, ¿qué es NextJS?
2.1 ¿Qué es NextJS?
NextJS es un framework nacido de React que incluye el Server Side Rendering de manera nativa. De esta manera, podemos prescindir del uso de un servidor de backend que haga esta misma tarea. Si conoces React de antemano, utilizar NextJS te será muy sencillo, pero también es recomendable realizar el tutorial que NextJS nos facilita para su comprensión.
Y ahora, ¿qué es SSR en Front?
2.2 ¿Qué es Server Side Rendering en Front?
En la introducción indicamos que lo que caracteriza a las SPA es que son un único fichero html que Javascript actualiza de manera dinámica, pero en el caso del SSR se renderizan todas y cada una de las páginas que componen la aplicación en el lado servidor. De esta manera, tenemos varias ventajas:
- La primera es que SSR ofrece una clara ventaja para tratar el SEO. Al renderizar todas y cada una de las páginas, permite a los buscadores, como Google, rastrear e indexar nuestra web al completo.
- La segunda ventaja es que permite cargar la página de manera más rápida. En las SPA, el contenido depende puramente de JavaScript, por lo que el usuario debe de esperar a que JavaScript cargue el contenido. Sin embargo, también hay que añadir que, dado que el contenido debe precargarse, el usuario debe experimentar una primera carga más lenta (ya que está cargando toda la aplicación web). Para ayudar al usuario a no sentirse perdido ante una página en blanco, existe el skeleton web, que permite mostrar los elementos que componen la página, sin contenido. Es como una preview de las zonas que componen la página. Puedes aprender más de esto en este artículo: Skeleton Screens in Plain JavaScript.
3. Pre-renderizado en NextJS:
NextJS nos proporciona dos funciones para el pre-renderizado de nuestra aplicación web: getServerSideProps y getStaticProps. Analicemos cada una de ellas.
3.1 getServerSideProps
export async function getServerSideProps(context){
return {
props: {}
}
}
Esta función asíncrona recibe un objeto por parámetro llamado context que nos permite, entre otras cosas, acceder al cuerpo de la petición http. De esta manera, podemos realizar peticiones http dentro de ésta, y rescatar la información que queramos mostrar en nuestra página web.
Esta información la devolveremos a modo de props, un objeto opcional que recibe el componente. Algo importante es que este objeto debe de ser serializable (o bien una Promesa que resuelva un objeto serializable).
Puedes profundizar más en este tema aquí: getServerSideProps en NextJS
3.2 getStaticProps
Al igual que ocurre con el caso anterior, NextJS nos proporciona otra función asíncrona llamada getStaticProps que funciona de manera muy similar a la anterior. Esta función recibe por parámetro context que nos permite, al igual que ocurre en el caso anterior, realizar peticiones http. Entonces, ¿cuál es la diferencia entre ambas?
3.3 getStaticProps vs getServerSideProps
En la documentación oficial de NextJS nos indican claramente la diferencia entre ambas funciones:
-
- getStaticProps es una función que se llama al momento de construir la página una vez, y es útil cuando pretendemos recuperar información estática. Es decir, supongamos que tenemos una aplicación que es un blog y queremos rescatar el contenido de un post en concreto. Ese contenido podemos considerarlo contenido estático dado que es una información que no es dinámica. Esta función le permite adelantarse a las peticiones del usuario y pre-renderizar el contenido, dado que no va a depender del usuario.
-
- getServerSideProps, en cambio, genera el HTML en cada petición. Esto es útil cuando esa información es dinámica. Sin embargo, NextJS siempre nos va a recomendar la primera opción, dado que aquí, como hemos dicho se genera el HTML en cada petición, lo que provoca un renderizado más lento que getStaticProps. Puedes leer más en su documentación oficial.
4. El componente Head
Dentro de la etiqueta <head> escribimos todas las etiquetas <meta> que nos ayudan con el SEO (puedes aprender más sobre todas las metaetiquetas de SEO en el tutorial Guía básica sobre SEO en Google que hay en este mismo portal). NextJS es consciente de la importancia de esta etiqueta, y por eso tiene su propio componente Head que nos facilita su estructura:
import Head from 'next/head'
Importando este componente facilitado por NextJS nos aprovechamos de varias ventajas:
- La primera es que nos ayuda a eliminar las metaetiquetas duplicadas. En una SPA o una aplicación normal, cuando nuestro código tiene ya un grosor y una extensión considerable, es posible que repitamos más de una misma metaetiqueta. Esto es considerado una mala práctica para el SEO. NextJS evita ese duplicado al proporcionarnos la posibilidad de añadir una propiedad key a las metaetiquetas. De esta manera, si ve que hay dos metaetiquetas con un mismo valor para la propiedad key, solo cargará la última:
function IndexPage() { return ( <div> <Head> <title>My page title</title> <meta property="og:title" content="My page title" key="title" /> </Head> <Head> <meta property="og:title" content="My new title" key="title" /> </Head> <p>Hello world!</p> </div> ) }Como podemos observar en este ejemplo facilitado por la documentación oficial de NextJS. Hay dos metaetiquetas que tienen el mismo valor para la propiedad key: title. Con este ejemplo, NextJS nos quiere demostrar dos cosas:
- Que podemos reutilizar el componente <head> tantas veces como queramos en cada página.
- Que nos permite despreocuparnos de no estar duplicando metaetiquetas.
- La segunda es que nos obliga a que cualquier etiqueta <title>, <meta> o, incluso <script> sean hijos directos del componente Head. Esto, lejos de ser una desventaja, es todo lo contrario, pues nos ayuda a asegurar que nuestra aplicación siga unas buenas prácticas que favorezcan al SEO.
5. Conclusión
Cuando nuestra aplicación es dependiente de un buen SEO, es interesante plantearnos alternativas como NextJS, Nuxt, Gatsby… Cualquier opción que nos permita incluir el server side rendering como manera de pre-renderizar el contenido de nuestra página y de facilitar a Google el indexado y rastreo de la misma. En este tutorial hemos tratado con NextJS como ejemplo de las ventajas que nos ofrecen estas alternativas, pero nunca está de más valorar otras opciones.
