Mejorar la performance de un e-commerce con blog recibiendo los datos de third parties

Introducción

La meta es construir una página (una home) con un header slider de imágenes a pantalla completa, con un slider de productos, un par de bloques de contenido fijo (típico CTA a secciones de una web) y un slider de artículos de un blog.

Los requisitos son obtener de otros servicios productos y artículos. El típico formulario de Newsletter también será un servicio externo.
El principal objetivo es tenerlo todo con buen rendimiento y probar a poner sleeps en los servicios externos (para emular malas third parties) y que a pesar de eso no se resienta la performance general de la página.

El primer paso que hemos realizado ha sido generar esos 3 sitios externos:

• Blog
• Newsletter
• Productos

Exportarán sus datos vía json.

Ya que los hacemos nosotros vamos a implementar la misma lógica en puntos en común, por ejemplo tanto los artículos como los productos tendrán imagenes, así que seguiremos una misma estructura en el json:

"images": {
    "header": {
        "alt": "lorem ipsum",
        "desktop": {
            "src": "http://...",
        }
    }
}

Esto lo hacemos para tener imágenes separadas por dimensiones de pantalla, con tal de poder obtener una imagen distinta para mobile y otra para desktop, por ejemplo.
Esta decisión ya tiene que ver con performance, ya que este diseño nos va a permitir mandar siempre la mejor imagen posible, para así impedir cargar una imagen demasiado grande cuando no sea necesario.

Una vez finalizado

Vamos a hacer un par de pruebas y comprobar diferencias, la primera forma en la que vamos a hacer esta home es haciendo vue components para cada bloque, sin SSR.  Aquí js debería bloquear lo justo el cliente como para que nos de algún problema de performance.

La segunda opción es cargar todos estos bloques directamente desde php, minimizando el js a lo más necesario, en nuestro caso esto serán los sliders.
Aquí la primera respuesta del servidor (TTFB) debería ser algo más elevada (aquí es donde deberemos realizar algún cambio de cara a performance) pero una vez lleguen los datos debería estar todo cargado sin bloqueo de js (más allá del que nos vaya a dar el propio slider)

Una vez tengamos las dos soluciones compararemos las métricas que nos entregue lighthouse en las dos versiones y después comenzaremos a poner sleeps muy bestias (5 segundos) en esos third parties y ver cuánto podemos mitigar ese problema.

En total serán 4 versiones:

• Mucho js
• Mucho js y sleeps en third parties
• Poco js
• Poco js y sleeps en third parties