¿Hacer Jamstack lento? Desafío aceptado.

“Jamstack es lentowwww”. Eso no es algo que se escuche a menudo, ¿verdad? Especialmente cuando uno de los principales puntos de venta de Jamstack es el rendimiento. Pero sí, es cierto que incluso un sitio Jamstack puede sufrir problemas de rendimiento como cualquier otro sitio.

No creas que al elegir Jamstack ya no tienes que pensar en el rendimiento. Jamstack puede ser rápido, realmente rápido , pero hay que tomar las decisiones correctas. Veamos si podemos detectar algunas de las malas decisiones que pueden conducir a un sitio Jamstack “lento”.

Para hacer eso, vamos a construir un sitio Gatsby realmente lento. Parece extraño ¿verdad? ¿¡Por qué haríamos eso intencionalmente!? Es el tipo de cosas en las que, si lo logramos, quizás podamos comprender mejor lo que afecta el rendimiento de Jamstack y cómo evitar los cuellos de botella.

Utilizaremos pruebas de rendimiento continuas y Google Lighthouse para auditar cada cambio. Esto resaltará la importancia de probar cada cambio de código. Nuestro sitio comenzará con una puntuación máxima de rendimiento de Lighthouse de 100. A partir de ahí, haremos cambios hasta que obtenga una puntuación de apenas 17. ¡Es más fácil de hacer de lo que piensas!

¡Empecemos!

Creando nuestro sitio Jamstack

Usaremos Gatsby para nuestro sitio de prueba. Comencemos instalando la CLI de Gatsby:

npm install -g gatsby-cli

Podemos crear un nuevo sitio de Gatsby usando este comando:

gatsby new slow-jamstack

Entremos cden el nuevo slow-jamstackdirectorio del proyecto e iniciemos el servidor de desarrollo:

cd slow-jamstackgatsby develop

Para agregar Lighthouse a la mezcla, necesitamos una producción de Gatsby. Podemos usar Vercel para alojar el sitio, dándole a Lighthouse una forma de ejecutar sus pruebas. Eso requiere instalar la herramienta de línea de comandos Vercel e iniciar sesión:

npm install -g vercel-clivercel

Esto creará el sitio en Vercel y lo colocará en un servidor activo. Este es el ejemplo que ya configuré y que usaremos para las pruebas.

Debemos usar Chrome para acceder directamente desde DevTools y ejecutar una auditoría de rendimiento. No es de extrañar que el sitio predeterminado de Gatsby sea rápido:

Una puntuación de 100 es lo más rápido que puedes conseguir. Veamos qué podemos hacer para frenarlo.

CSS lento

Los marcos CSS son geniales. Ellos pueden hacer mucho trabajo pesado por usted. Al decidir sobre un marco CSS, use uno que sea modular o emplee CSS-in-JS para que el único CSS que necesite sea el que está cargado.

Pero tomemos la mala decisión de utilizar un marco completo solo para diseñar un componente de botón. De hecho, tomemos incluso el marco más pesado mientras estamos en ello. Estos son los tamaños de algunos frameworks populares:

¡Muy bien, SemanticUI lo es! La forma “correcta” de cargar este framework sería usar un paquete Sass o Less, que nos permitiría elegir las partes del framework que necesitamos. La forma incorrecta sería cargar todos los archivos CSS y JavaScript en headHTML. Eso es lo que haremos con la hoja de estilo completa de SemanticUI. Además, vamos a vincular jQuery porque es una dependencia de SemanticUI.

Queremos que estos archivos se carguen en el encabezado, así que saltemos al html.jsarchivo. Esto no está disponible en el srcdirectorio hasta que ejecutemos un comando para copiar el valor predeterminado del caché:

cp .cache/default-html.js src/html.js

Eso nos da html.jsen el srcdirectorio. Ábralo y agregue la hoja de estilo y los scripts necesarios:

link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/semantic-ui@2.4.2/dist/semantic.css"/linkscript src="https://code.jquery.com/jquery-3.1.1.js"/scriptscript src="https://cdn.jsdelivr.net/npm/semantic-ui@2.4.2/dist/semantic.js"/script  

Ahora envíemos los cambios directamente a nuestra URL de producción:

vercel --prod

Bien, veamos la auditoría…

Hemos reducido la velocidad del sitio a una puntuación de 66. Recuerde que ni siquiera estamos utilizando este marco en este momento. Todo lo que hicimos fue cargar los archivos en el encabezado y eso redujo la puntuación de rendimiento en un tercio. Nuestro tiempo de interacción (TTI) saltó de unos rápidos 1,9 segundos a unos notables 4,9 segundos. Y observe los posibles ahorros que podríamos obtener con las recomendaciones de Lighthouse.

Dependencias de marketing lento

A continuación, veremos las etiquetas de marketing y cómo estos scripts de terceros pueden afectar el rendimiento. Supongamos que trabajamos con un departamento de marketing y quieren empezar a medir el tráfico con Google Analytics. También tienen una campaña en Facebook y también quieren realizar un seguimiento.

Nos dan los detalles de los scripts que debemos agregar para que todo funcione. Primero, para Google Analytics:

script async src="https://www.googletagmanager.com/gtag/js?id=UA-4369823-4"/scriptscript  dangerouslySetInnerHTML={{ __html: `  window.dataLayer = window.dataLayer || [];  function gtag(){dataLayer.push(arguments);}  gtag('js', new Date());  gtag('config', 'UA-4369823-4');  `}}/

Luego para la campaña de Facebook:

script  dangerouslySetInnerHTML={{ __html: `    !function(f,b,e,v,n,t,s)    {if(f.fbq)return;n=f.fbq=function(){n.callMethod?    n.callMethod.apply(n,arguments):n.queue.push(arguments)};    if(!f._fbq)f._fbq=n;n.push=n;n.loaded=!0;n.version='2.0';    n.queue=[];t=b.createElement(e);t.async=!0;    t.src=v;s=b.getElementsByTagName(e)[0];    s.parentNode.insertBefore(t,s)}(window, document,'script',    'https://connect.facebook.net/en_US/fbevents.js');    fbq('init', '3180830148641968');    fbq('track', 'PageView');    `}}/noscriptimg src="https://www.facebook.com/tr?id=3180830148641968ev=PageViewnoscript=1"//noscript

Colocaremos estos scripts dentro html.js, nuevamente en la headsección, antes de la /headetiqueta de cierre.

Al igual que antes, vayamos a Vercel y volvamos a ejecutar Lighthouse:

vercel --prod

Vaya, el sitio ya se ha reducido a 51 y todo lo que hemos hecho es agregar un marco y un par de scripts miserables. Juntos, han reducido el puntaje en la friolera de 49 puntos, casi la mitad de donde empezamos.

Imágenes lentas

Aún no hemos agregado ninguna imagen al sitio, pero sabemos que lo haríamos en un escenario de la vida real. Vamos a agregar 100 imágenes a la página. Claro, 100 es mucho para una sola página, pero sabemos que las imágenes suelen ser las mayores culpables de las páginas web infladas, por lo que es mejor dejarlas brillar.

Empeoraremos un poco las cosas cargando las imágenes en caliente directamente desde https://placeimg.com en lugar de publicarlas en nuestro propio servidor.

Abramos index.jsy coloquemos este código, que recorrerá 100 instancias de imágenes:

const IndexPage = () = {  const items = []  for(var i = 0; i  100; i++) {    const url = `http://placeimg.com/640/360/any?=${i}`    items.push(img key={i} alt={i} src={url} /)  }    return (    Layout      // ...      {items}      // ...    /Layout  )}

Las 100 imágenes son todas diferentes y se cargarán a medida que se carga la página, bloqueando así la representación. Bien, vayamos a Vercel y veamos qué pasa.

vercel --prod

Bien, ahora tenemos un sitio Jamstack muy lento . Las imágenes están bloqueando la representación de la página y el TTI es ahora de 16,5 segundos. Tomamos un sitio Jamstack muy rápido y lo redujimos a una puntuación Lighthouse de 17: ¡una reducción de 83 puntos!

Ahora bien, es posible que piense que nunca tomaría estas malas decisiones al crear una aplicación. Pero estás perdiendo el punto. Cada elección que hacemos tiene un impacto en el rendimiento. Es un equilibrio y el rendimiento no es gratis. Incluso en sitios Jamstack.

Hacer que Jamstack vuelva a ser rápido

Has visto que no podemos ignorar el rendimiento del lado del cliente cuando usamos Jamstack.

Entonces, ¿por qué la gente dice que Jamstack es rápido? Bueno, la principal ventaja de Jamstack (o del uso de generadores de sitios estáticos en general) es el almacenamiento en caché. Los archivos estáticos se almacenan en caché en el borde, lo que reduce el tiempo hasta el primer byte (TTFB).

Esto siempre será más rápido que ir a un servidor web de origen único antes de generar la página. Esta es una gran característica de Jamstack y te brinda la oportunidad de luchar para crear una página que pueda llegar a 100 en Lighthouse. (Pero bueno, como nota al margen, recuerde que las excelentes puntuaciones no siempre son indicativas de una experiencia de usuario real ).

Mira, ¡te dije que podíamos hacer que Jamstack fuera lento! También hay muchas otras cosas que pueden ralentizarlo, pero es de esperar que esto entienda el punto.

Mientras hablamos de rendimiento, aquí están algunos de mis artículos favoritos sobre rendimiento aquí en CSS-Tricks:

• La guía completa para la carga diferida de imágenes
• Las diferentes perspectivas sobre CSS-in-JS
• Guiones de terceros