DEV Community: Joel Humberto Gómez Paredes

Sincronizando mi AGENTS.md

Joel Humberto Gómez Paredes — Wed, 11 Feb 2026 20:15:35 +0000

Una de las cosas mas importantes para el AI Assisted development es el contexto. Este es una forma de darle instrucciones a nuestros agentes para que alucinen lo menos posible y realicen lo que necesitamos.

Cada agente/asistente/tool tiene su forma de definir un archivo que sea su fuente de la verdad, muchos están adoptando el uso de un archivo especial AGENTS.md lo cual es genial porque los estandares son buenos para guiar una industria y darle cierta estabilidad.

Yo adopte este mindset y si bien hay algunas herramientas que adoptan esto, hay otras que tienen un soporte mixto dan soporte al AGENTS.md pero también a su propio archivo. Peeeeeeero también hay otras herramientas que no lo hacen.

Sincronizando contexto

Para resolver este "problema" cree una tool bastante simple (por ahora) llamada @dezkareid/ai-context-sync.

La cual usa el archivo AGENTS.md como fuente de la verdad y a traves de algunas estrategias configura/enlaza este archivo con el que necesitan algunas herramientas como Claude Code y Gemini CLI.

Pueden probarla usando npx

npx @dezkareid/ai-context-sync sync

Dependiendo de la estrategia que selecciones creará un archivo de configuración y así dependiendo de esta configuración puede generar esa sincronización nuevamente.

Como desarrolladores nunca es recomendable estar atado a una sola herramienta, es por eso estamos constantemente analizando e iterando.

Durante este pequeño desarrollo agregue soporte para seleccionar alguna estrategia directamente.

npx @dezkareid/ai-context-sync sync --strategy claude
npx @dezkareid/ai-context-sync sync --strategy gemini
npx @dezkareid/ai-context-sync sync --strategy all
npx @dezkareid/ai-context-sync sync --strategy "claude, gemini"

No es una herramienta que uses muchas veces en tu ciclo de desarrollo o quizás si, no lo se, solo las descargas lo dirán jeje.

Motivación

Esto no es un problema que vaya mas allá del copiar y pegar, el "problema" es tener que modificar o mas bien tener contexto de que cosas hay que modificar.

Tener un markdown para cada herramienta es una pesadilla pero es peor tener información y contexto duplicado.

El context engineering y el One Piece son reales.

Yo estoy tratando de definir mi estado del arte en AI y también para mis equipos de trabajo, entonces esto fue algo que solucionó mi problema por el momento, así que soy feliz.

Futuro

Algunos editores como cursor y windsurf ya incluyen el soporte para AGENTS.md pero no antigravity, así que probablemente en lo que dan soporte agregaré una regla que permita hacer referencia a este archivo.

Como dije antes, cada tool puede seleccionar el camino que desee, adoptar un estandar o salir de el para generar algo diferente. Lo hermoso de esta época es que ahora pasamos menos tiempo escribiendo código y mas tiempo diseñandolo.

Publicación de paquetes npm turborepo, trusted publisher, pnpm

Joel Humberto Gómez Paredes — Sat, 07 Feb 2026 22:03:49 +0000

Hace una semana me di a la tarea de hacer un update a mi monorepo personal (aún seguimos trabajando en ello).

Dentro de todas las tareas tuve que realizar la de publicar paquetes fue de las más complicadas y vengo a explicarles un poco del porque puede ser complejo.

Old way

Mi proceso anterior era bastante simple:

Entrar a npmjs.
Generar un token de acceso.
Agregar el token a tu proceso de publicación.
Crear la env var de NPM_TOKEN y el GITHUB_TOKEN a semantic-release.

Y listo, pero se cambiaron ciertas políticas de seguridad en npmjs que ahora sugiere el uso de trusted publishing para la publicación usando OpenID Connect en lugar de un token tradicional.

Configuración de trusted publishing

Antes de crear la configuración del trusted publisher en npmjs, tu paquete debe existir en npmjs si o si.

En el caso de que vayas a publicar un paquete nuevo, lo que debes hacer es una publicación manual (pnpm publish --tag dummy) o usar una herramienta llamada setup-npm-trusted-publish.

Ahora debes acceder a la sección de configuración de tu paquete en https://www.npmjs.com/package/<package-name/access o https://www.npmjs.com/package/<scope>/<package-name/access. Después debes agregar los datos de tu trusted publisher (github o gitlab).

Debe aparecerte algo similar a esto:

Una vez seleccionado solo hay que llenar datos:

Organización o usuario
Repositorio
Nombre del archivo de tu workfflow (incluyendo extensión). Nota: este debe estar dentro de tu folder de .github/workflows .

En mi caso fue:

dezkareid
dezkareid
ci-packages.yml

Listo ya la configuración esta completa, ahora hay que realizar la configuración de nuestro publisher en nuestro workflow.

Configuración de trusted publishing en Github Action

Lo primero que necesitamos es configurar los permisos en nuestro job

permissions:
  id-token: write

Estrictamente solo necesitamos el permiso de id-token para la conexión usando OpenID Connect y podríamos usar npm publish, pero como uso semantic-release para subir el tag a github y el changelog, entre otras cosas. Mi configuración es la siguiente:

permissions:
  contents: write
  issues: write
  pull-requests: write
  id-token: write

Aquí hay un ejemplo de un action que usa esta configuración.

Mi configuración de semantic-release

{
  "plugins": [
    "@semantic-release/commit-analyzer",
    "@semantic-release/release-notes-generator",
    "@semantic-release/changelog",
    "@semantic-release/npm",
    [
      "@semantic-release/git",
      {
        "assets": [
          "CHANGELOG.md"
        ]
      }
    ],
    "@semantic-release/github"
  ]
}

En esta parte tuve algunos problemas debido a mi arquitectura y a mi stack.

Yo uso una arquitectura de monorepo y no de polirepo, eso agrega complejidad ya que debes ubicarte especificamente en el proyecto que debes publicar. Ademas de que estoy usando pnpm entonces ocurrió algo raro que me pedía autenticarme. Al ser un monorepo uso workspaces y no de manejan de la misma manera usando npm que pnmp.

Entre los problemas que enfrente fueron los siguientes:

Capa 8, no agregué correctamente el nombre del archivo de mi workflow, me di cuenta de esto porque al tratar de publicar el plugin de npm verifica si el OpenID connect esta bien configurado y me decía que no encontraba la configuración.
Tenía un comando release usando que era ejecutado directamente por turborepo, el problema es que este aplica un filtro de variables de entorno y debes indicar explicitamente cuales necesitas. Lo solucioné usando el folder con el cambio como working directory y ejecutando semantic-release directamente
El plugin de semantic release de npm no estaba funcionando, el problema no era el plugin sino mi stack. Al parecer había un detalle de como se manejaba la autenticación, la documentación de las herramientas por lo regular contempla que estes usando npm pero a bajo nivel puede ser que aunque tengas una herramienta que funcione de manera similar no siempre va a funcionar con tu stack. La solución fue instalar el plugin @anolilab/semantic-release-pnpm.

Mi configuración quedó de la siguiente manera

{
  "plugins": [
    "@semantic-release/commit-analyzer",
    "@semantic-release/release-notes-generator",
    "@semantic-release/changelog",
    "@anolilab/semantic-release-pnpm",
    [
      "@semantic-release/git",
      {
        "assets": [
          "CHANGELOG.md"
        ]
      }
    ],
    "@semantic-release/github"
  ],
  "extends": "semantic-release-monorepo"
}

Y con esto ahora ya puedo publicar paquetes nuevamente usando mi stack preferido. Te dejo mi workflow para que puedas observarlo y si te sirve lo puedas replicar :D

Textos y fragmentos contenido relevante en tu web

Joel Humberto Gómez Paredes — Sat, 04 Oct 2025 23:30:31 +0000

Uno de los atributos mas importantes para tu web es el "discoverability" por esto me refiero a como el usuario encuentra tu producto. En este caso me enfocaré en la web. Hay muchos medios por el cual el usuario encuentra tu web pero sin duda alguna mucho de ese tráfico será mediante el buscador.

Mediante el Search Engine Optimization (SEO) podemos hacer modificaciones a nuestra web para incrementar nuestro ranking y sobresalir entre otras opciones (competencia).

Hay muchas formas de optimizar pero en este post me enfocaré en el contenido y una parte que casi no he visto que se aborde son los fragmentos de texto (text fragments).

En el mundo de la web, el contenido es el rey

De las partes que forman una URL sin duda alguna hemos visto fragmentos pero seguramente no hemos usado fragmentos de texto.

Un fragmento de texto nos permite compartir un link hacia nuestro contenido, que el navegador haga scroll hacia el fragmento y que se aplique un highlight para que el usuario pueda visualizarlo.

Fuente

¿Porqué es importante?

Permite que el usuario encuentre lo que busca de manera rápida, incluso los buscadores ofrecen esos fragmentos como referencia y también nos da la posibilidad de priorizar el contenido mas relevante dentro de nuestra web si queremos hacer difusión.

Esta feature esta definida en los estándares web de la comunidad por si quieren darle un vistazo :)

¿Cómo la uso?

Primero analicemos la sintaxis

https://example.com#:~:text=[prefix-,]textStart[,textEnd][,-suffix]

En la URL observamos que después del símbolo de hash # se encuentran los siguientes simbolos :~:, a esto se le conoce como fragment directive. Esta directiva le dice al browser que debe buscar una secuencia de texto (básicamente es como un CTRL + F o Command + F).

La directiva de texto text= nos indica el fragmento de texto que se va a buscar. Una nota importante es que el texto a buscar debe esta codíficado para que se pueda buscar.

La forma más simple de utilizar un fragmento de texto es: codificar un texto y agregalo después de la directiva. Ejemplo

Anteriormente te había dicho que es como un CTRL + F o Command + F pero podemos agregar como debe terminar el fragmento de texto, hasta prefijos y sufijos (ambos opcionales).

Voy a usar como ejemplo el siguiente codePen

Cuando solo usamos #:~:text=texto solo buscará ese texto observen. Por cierto, esto no funciona en iframes y si no hace hightlight puede ser que algún input este robando foco.

Si agregamos la palabra "anterior":

https://codepen.io/dezkareid/pen/XJXpXaJ#:~:text=texto,anterior

Veremos como selecciona mas de una línea porque le indicamos que el fragmento de texto debe iniciar y terminar.

Si queremos agregar un prefijo lo único que debemos hacer es agregarlo al principio del valor de la directiva seguido de un dash -, aquí yo estoy usando la palabra prefijo:

https://codepen.io/dezkareid/pen/XJXpXaJ#:~:text=prefijo-,texto,anterior

En este ejemplo notarás que el prefijo no se selecciona, esto es porque se usa como criterio de búsqueda pero lo que define la selección.

Si queremos usar un posfijo sería muy similar al prefijo pero este debe ir al final y el dash se pone al principio del texto.

https://codepen.io/dezkareid/pen/XJXpXaJ#:~:text=texto,anterior,-posfijo

Adicionalmente si quieren agregar estilos custom a la selección pueden usar el pseudo-selector ::target-text. Este esta disponible según Baseline desde el 2024.

Dónde puedo usarla

Contenidos como blogposts y artículos son ideales porque quieres transmitir una idea principal, algo que aporta valor y que si bien se puede actualizar o "cambiar", normalmente el cambio son correcciones o nuevos aportes.

No deberías usar esto en contenido que cambia constantemente porque si el contenido cambia el link deja de ser útil.

Hay que ser cuidadosos con estos links y no usarlos para todo porque se puede volver inmantenibles en contenido que cambia constantemente.

Conclusiones

Esta feature es algo simple pero que puede apoyar a tener mejor discoverability de su contenido, ya sean en sus estrategias de tráfico orgánico, marketing, campañas, etc. Ya que permite que sus usuarios encuentren el contenido que ustedes quieren que destaque.

Espero les haya gustado y lo compartan :D

Cargando imágenes responsive con CSS

Joel Humberto Gómez Paredes — Wed, 01 Oct 2025 20:05:51 +0000

Uno de los recursos más usados en la web son las imágenes, hay muchas estrategias para cargar imágenes de manera eficiente, en esta ocasión voy a mostrarles una alternativa que no he visto.

Imágenes responsivas con srcset

Una de las formas más fáciles de cargar imágenes responsive es el atributo srcset el cual nos permite agregar una imagen dependiendo del tipo de resolución.

<image
  width="360px"
  height="360px"
  src="https://images.wikidexcdn.net/mwuploads/wikidex/thumb/4/43/latest/20190406170624/Bulbasaur.png/400px-Bulbasaur.png"
  srcset="https://images.wikidexcdn.net/mwuploads/wikidex/thumb/4/43/latest/20190406170624/Bulbasaur.png/800px-Bulbasaur.png 2x"

/>

Gracias wikidex :3

En este ejemplo el browser cargará automaticamente la imagen que mejor se adapte a las condiciones del browser actual, en el caso que nuestra pantalla tenga el device pixel de 2, se cargará el srcset y en caso contrario se cargará el src normal.

Como nota, también podríamos utilizar esta sintaxis y visualmente resultaría lo mismo


<image
  width="360px"
  height="360px"
  srcset="https://images.wikidexcdn.net/mwuploads/wikidex/thumb/4/43/latest/20190406170624/Bulbasaur.png/400px-Bulbasaur.png 360w https://images.wikidexcdn.net/mwuploads/wikidex/thumb/4/43/latest/20190406170624/Bulbasaur.png/800px-Bulbasaur.png 800w"
/>

Hay 3 posibles detalles con esta estrategia:

No tenemos un control explícito de que imagen se carga para ciertas condiciones mas allá de la resolución.
La resolución esta definida no por el tamaño del elemento sino el de la pantalla
La sintaxis puede ser un poco compleja de entender

En un caso de uso que tuve necesitaba cargar una imagen pero solo en resoluciones tablet hacia arriba (vamos a decir que 800px), en mobile no debía mostrarse y por ende tampoco descargarse.

Para este caso srcset no me resultaba ideal porque haga lo que haga siempre se descargará una imagen, también se puede utilizar JS para ver si el dispositivo es mobile y en ese caso no agregar el atributo srcset a la imagen.

Hay muchas alternativas pero no me convencia mucho el uso de JS para este tipo de escenarios, así que pensé en usar CSS y custom properties.

Imágenes responsive con custom properties

En mi caso la imagen era mas que nada un elemento decorativo que descriptivo no tenía problemas con la accesibilidad. Lo cual podría mitigar con aria attributes pero siempre es mejor usar lo nativo que tratar de ser muy listo.

La clave para decidir usar este approach es que cuando usamos una imagen como background en CSS y lo combinamos con display: none la imagen no se descarga (que trucazo).

Esta alternativa no es una propuesta para que se use siempre, a mi me funcionó para mi caso de uso

El HTML es el siguiente

<section>
  <div
    class="image image-responsive"
    style="
      --bg-image: url('https://images.wikidexcdn.net/mwuploads/wikidex/thumb/5/56/latest/20200307023245/Charmander.png/800px-Charmander.png');
    "
  >
  </div>
  <image
    class="image"
    srcset="https://images.wikidexcdn.net/mwuploads/wikidex/thumb/4/43/latest/20190406170624/Bulbasaur.png/400px-Bulbasaur.png 360w, https://images.wikidexcdn.net/mwuploads/wikidex/thumb/4/43/latest/20190406170624/Bulbasaur.png/800px-Bulbasaur.png 800w"
  />
</section>

Y el CSS

section {
  display: flex;
}

.image {
  height: 300px;
  width: 300px;
  display: none;
}

.image-responsive {
  background-image: var(--bg-image, "");
  background-size: cover;
}

@media (width > 800px) {
  .image {
    display: block;
  }
}

En el srcset cargué 2 imágenes, aunque solo nos interesa la segunda la primera es mas que nada para mostrar la sintaxis de srcset

Recomiendo mirar el código y después ir al pen que cree, si estas en una resolución menor a 800px no verás nada pero en caso contrario verás a un charmander y a un bulbasaur.

Abre las devtools, pon el tab de network, filtra los request para solo mostrar los de imagen, haces un resize de pantalla a 360px y recarga. Si hicieste esto y revisas en las imágenes que se descargaron podrás ver que la imagen de bulbasaur se descarga pero no la de charmander.

Aunque en cierto aspecto la legibilidad de este approach no es muy buena ya que agregar custom properties directamente en el elemento y no a traves de una clase agrega mucho texto y es muy delicado en la parte del setup, ya que srcset es la solución ideal para el manejo de imágenes responsive. Pero también nos permite tener mayor claridad de que imagen se va a cargar ya que podrías tener varias custom properties para cargarse en escenarios como landscape o dark sin necesidad de usar JS.

Otro punto a favor o en contra (dependiendo de como lo veas) es que si haces un resize de pantalla se cargaran otras imágenes que hayas definido, dependiendo de la resolución ya que css es reactivo. Puede que quieras eso o no, con srcset solo se carga la primera imagen seleccionada de acuerdo al criterio definido así que no importa si se hace mas grande la pantalla o mas chica, solo se usará la que se descargó en un inicio.

Speculation Rules API: Selectores y carga dinámica

Joel Humberto Gómez Paredes — Sun, 07 Jul 2024 08:50:53 +0000

En un post anterior escribí un poco sobre Speculation Rules API y como podíamos usarla para hacer un prerender de páginas para dar una sensación de navegación instantanea a los usuarios.

En este post vamos a hablar sobre como cargar dinámicamente un script con nuestras Speculation Rules y como usar selectores para seleccionar las páginas a las que queremos hacer prerender. Para ello planteemos el siguiente escenario.

Basados en la analítica de nuestro sitio web, determinamos que los usuarios tipo A, en un 80% de los casos hacen click en el link 1 y los usuarios tipo B, en un 89% de los casos hacen click en link 2.

Al analizar este caso vemos que tenemos un caso concreto donde podemos hacer prerender. Recuerden, el prerender es útil pero también es peligroso ya que al final quieras o no estas consumiento recursos.

Bueno para este caso necesitamos

Nuestra web (página principal, pagina a la que apunte el link 1 y link 2 respectivamente)
Un script para cargar nuestras reglas de manera dinámica

Nuestra web

Primero nuestra web, algo simple para evitar mas carga cognitiva de la necesaria

Pagina principal

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Main page</title>
  </head>
  <body>
    <h1>Main page</h1>
    <a href="/link1.html" class="link1">Link 1</a>
    <br />
    <a href="/link2.html" class="link2">Link 2</a>
    <script async defer type="application/javascript">
      /* Todo nuestro código irá aquí */
    </script>
  </body>
</html>

Pagina link 1

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Link 1</title>
  </head>
  <body>
    <h1>Link 1</h1>
    <a href="/">Back to main page</a>
  </body>
</html>

Página link 2

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Link 2</title>
  </head>
  <body>
    <h1>Link 2</h1>
    <a href="/">Back to main page</a>
  </body>
</html>

Script

Nuestro script tendrá 2 partes primero una función que creará nuestro speculation rules object, este recibirá al usuario para decidir el contenido de la regla y la segunda parte es la que carga el script

function createSpeculationRulesObject(user) {
  const mapHrefByType = {
    A: '/link1.html',
    B: '/link2.html',
  };
  return {
    prerender: [
      {
        where: {
          href_matches: mapHrefByType[user.type],
        },
      },
    ],
  };
}

function injectSpeculationRules(speculationRulesObject) {
  const scriptType = 'speculationrules';
  if (HTMLScriptElement.supports && HTMLScriptElement.supports(scriptType)) {
    const specScript = document.createElement('script');
    specScript.type = scriptType;
    specScript.textContent = JSON.stringify(speculationRulesObject);
    document.body.append(specScript);
  }
}

const user = {
  type: 'A',
};
const speculationRulesObject = createSpeculationRulesObject(user);
injectSpeculationRules(speculationRulesObject);

Vamos analizar directamente el speculation rules object

{
  prerender: [
    {
      where: {
        href_matches: mapHrefByType[user.type],
      },
    },
  ],
};

En ejemplos anteriores usabamos una lista de urls usando la propiedad urls: ["link1", "link2", "etc"](doc). En este ejemplo podríamos agregar a la lista la página sin ningún problema. Pero queremos usar la propiedad where(doc) ya que es más flexible, en este momento usamos la propiedad href_matches(doc) con la cual se hace el prerender de los elementos que apunten a las urls que hagan match pero también podríamos usar la propiedad selector_matches(doc). Si ejecutas el ejemplo con un servidor y abres tus devtools en Application veras lo siguiente:

¿Qué es lo que pasó?

Antes de explicar lo que pasó haz lo siguiente, con las devtools abiertas en Speculative loads, ve al enlace link1 y haz un click largo, veras lo siguiente

Ahora si se viene lo chido, el speculation rules object hay una propiedad llamada eagerness (info aquí). Esta indica cuando debe hacerse el prerender y toma un valor por default dependiendo de que propiedades declare el objeto.

Cuando el objeto define la propiedad urls el valor por defecto de eagerness será "https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script/type/speculationrules#immediate", lo que quiere decir que el prerender se hará lo más rápido posible.

Cuando el objeto define la propiedad where el valor por defecto de eagerness será "conservative", lo que quiere decir que el prerender se hará hasta que ocurra un evento como un click sobre el link.

El objeto speculation rule no puede tener la propiedad urls y where a la vez

Para este ejemplo queremos que cargue inmediatamente así que definamos eagerness con el valor immediate y cambiemos el usuario que le pasamos con type B (solo para variar). Nota, esta API es muy sensible a typos, así que si te equivocas al definir alguna propiedad dejará de funcionar.

function createSpeculationRulesObject(user) {
  const mapHrefByType = {
    A: '/link1.html',
    B: '/link2.html',
  };
  return {
    prerender: [
      {
        where: {
          href_matches: mapHrefByType[user.type],
        },
        eagerness: 'immediate',
      },
    ],
  };
}

Ahora si recargas la página veras como el prerender se realiza sin necesidad de una interacción.

Para finalizar, vamos a cambiar un poco el script y en lugar de usar urls usaremos selectores.

function createSpeculationRulesObject(user) {
  const mapSelectorsByType = {
    A: '.link1',
    B: '.link2',
  };
  return {
    prerender: [
      {
        where: {
          selector_matches: mapSelectorsByType[user.type],
        },
        eagerness: 'immediate',
      },
    ],
  };
}

Tenemos exactamente el mismo resultado. Como dato extra, si al momento de agregar la regla no hay algún elemento que haga match, no hay ningún problema, en cuanto exista el prerender se ejecutará.

Conclusiones

Puedes usar Speculation Rules API para hacer prerender dinámico basada en la data de tu aplicación. En este caso usamos "immediate" pero en casos de la vida real podemos tomar en cuenta mas factores para hacer la inyección de reglas o incluso usar un eagerness con el valor moderate (doc) que inicia el render cuando el elemento esta en el viewport y se hace un hover. Si bien podemos cargar una páginas más rápido también hay que ser cuidadosos con el consumo de recursos

Instant Navigation con Speculation Rules API

Joel Humberto Gómez Paredes — Wed, 26 Jun 2024 05:54:45 +0000

Uno de las fantasías de todo frontend es que la navegación entre las diferentes partes de nuestra web sea instantanea como si de alguna manera la web estuviera lista para la página a la que queremos acceder.

El browser nos ofrece mecanismos como los resource hints para poder hacer precargas (entre los mas conocidos preload y prefetch) de recursos lo cual nos da la posibilidad de reducir tiempos de carga.

Antes de tenía un resource hint llamado prerender pero fue eliminado por múltiples bugs pero ahora regreso en forma de ficha con la Speculation Rules API.

Speculation Rules API

Antes de empezar, una aclaración preload y prefetch sirven para hacer el request de recursos para que cuando se usen ya se hayan descargado (Hay mas diferencias pero quiero simplificar). Esto en archivos de assets esta perfecto pero cuando se solicitan documentos HTML estos solo se renderizarán cuando ese documento se cargue en el contexto del browser.

Si quisieramos cargar algún recurso preload y prefetch son suficientes, esto normalmente tiene mayor uso en una Single Page App (SPA), en una SPA la navegación es mas compleja porque todo se administra dentro del contexto de la aplicación. Cuando tenemos una Multi Page App (MPA) donde la navegación es simple pero se cambia todo el contexto de la aplicación. Aquí es donde Speculation Rules API nos permite especificar que URLs podemos prerenderizar para darnos una sensación de inmediates.

Advertencia

La implementación de Speculation Rules API también tiene consecuencias, al hacer un prerender nuestro JS se ejecuta. Si tenemos analytics podemos estar introduciendo ruido a nuestras métricas ya que estamos "Especulando" ya que nada nos garantiza que el usuario va a acceder a las urls que especificamos.

Adicionalmente sería bueno considerar el tipo de dispositivo y conexión

Demo

Cree un sitio sencillo con 3 páginas: index, page2 y page3 (que creativo).

El servidor que cree para servir el contenido hace que cualquier URL que termine en .html tendrá un delay de 2 segundos (Esta parte es opcional y se hizo por motivos dramáticos XD)

const express = require("express");
const path = require("path");

const app = express();
const port = process.env.PORT || 9000;

// Define the static files directory
const staticPath = path.join(__dirname, "public");

// Middleware to delay response for HTML files
app.use((req, res, next) => {
  if (req.url.endsWith(".html")) {
    setTimeout(() => next(), 2000); // Delay by 2 seconds
  } else {
    next();
  }
});

// Serve static files
app.use(express.static(staticPath));

app.listen(port, () => {
  console.log(`Server listening on port ${port}`);
});

Código Page2

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Page 2</title>
  </head>
  <body>
    <h1>Page 2</h1>
  </body>
</html>

Código Page3

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Page 3</title>
  </head>
  <body>
    <h1>Page 3</h1>
  </body>
</html>

Código index.html

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Main</title>
    <script type="speculationrules">
      {
        "prerender": [
          {
            "urls": ["page2.html"]
          }
        ]
      }
    </script>
  </head>
  <body>
    <h1>Speculation API</h1>
    <h2><a href="page2.html">Page 2</a></h2>
    <h2><a href="page3.html">Page 3</a></h2>
  </body>
</html>

La Speculation Rules API puede ser usada como un tipo de script o también como un JSON externo pero este debe ser especificado en un Header.

Speculation Rules API no es un API que pueda usarse directamente con JS, funciona como un JSON donde especificas una configuración.

Si usas Chrome, antes de ejecutar el demo te sugiero abrir las developer tools, ve a Application y busca en el panel izquierdo una sección llamada "Speculative loads". Ahí podras ver que la página se cargó (aunque igual podrías usar Network).

Da click en Page 3 y después a Page 2. ¿Ves la diferencia? Ahora si, vamos a explicar al responsable de lo que acaba de suceder.

<script type="speculationrules">
      {
        "prerender": [
          {
            "urls": ["page2.html"]
          }
        ]
      }
    </script>

En la referencia de Speculation Rules API nos especifíca que la configuración es un objeto con 2 propiedades prerender y prefetch. Por ahora nos enfocaremos en prerender.

De acuerdo a la documentación las reglas que usamos tienen propiedades como urls, un arreglo donde ponemos las URLs que queremos prerenderizar.

También existe la propiedad where para hacer una selección mas avanzada de aquello que queremos prerenderizar (lo abordaremos en otros posts)

Hay una propiedad llamada eagerness que le indica al browser "cuando" se debería hacer el prefetch/prerender de los recursos especificados en la regla.

Por defecto para lo especificado en "urls", el eagerness tiene un valor de "immediate". Lo que quiere decir que el prerendering comenzará tan pronto como sea posible. Prueba agregando esa propiedad con el valor de "moderate" (no olvides abrir las devtools para ver que sucede)

<script type="speculationrules">
      {
        "prerender": [
          {
            "urls": ["page2.html"],
            "eagerness": "moderate"
          }
        ]
      }
    </script>

Te dirá que hay una regla que no se ha disparado

Ahora pon el cursor sobre el link y veras como se dispara el evento y hace el prerender. Esto es muy util para evitar prerenders innecesarios.

En futuros post abordaremos mas sobre los diferentes tipos de eagerness. Nota: tu no tienes forma de saber cuando ocurriran estos eventos de manera exacta, eso lo decide el browser.

Consideraciones

Tu script de analytics y ejecución de ciertos scripts que se deben ejecutar únicamente cuando el usuario visite el documento tendrá que tener código adicional.

Mira el siguiente código rob...inspirado en la documentación de Mozilla

if (document.prerendering) {
  document.addEventListener("prerenderingchange", initAnalytics, {
    once: true,
  });
} else {
  initAnalytics();
}

Si bien el API no puede ser usada directamente con JS, puedes usar JS para agregarlas dinámicamente

if (
  HTMLScriptElement.supports &&
  HTMLScriptElement.supports("speculationrules")
) {
  const specScript = document.createElement("script");
  specScript.type = "speculationrules";
  const specRules = {
    prefetch: [
      {
        source: "list",
        urls: ["/next.html"],
      },
    ],
  };
  specScript.textContent = JSON.stringify(specRules);
  document.body.append(specScript);
}

Habrá mas post, sobre esta API en el futuro, integraciones con react y como usarla en producción sin preocupaciones aunque esta API sea experimental.

Si les gusta compartan, sino pues también XD. Nos vemos en futuros posts

Persistencia para frontends

Joel Humberto Gómez Paredes — Mon, 24 Jun 2024 07:39:21 +0000

Uno de los mitos en el desarrollo web es que los developers especializados en frontend es que en su trabajo no involucra la construcción de bases de datos, solo consultas a APIs.

Nada mas lejos de la verdad, si bien la fuente de la verdad absoluta siempre serán los datos provenientes de una API. La data de los endpoints por si sola no tiene significados hasta que no la estructuramos y la usamos.

Cuando definimos el estado de una aplicación, estructuramos data de modo que la UI puede mostrar información y/o ciertas acciones pueden ser permitidas o negadas.

Otro escenario es cuando queremos que cierta data persista pero solo en el navegador. ¿Porqué no todo en el server? Bueno crear/mantener un endpoint involucra un costo y hay veces que la persistencia que se busca no requiere de un servidor (ejemplo: un token de autenticación).

Bueno continuamos, normalmente la data del estado de una aplicación esta in-memory y cuando abrimos otra tab, tiene su propio stack de memoria donde la data no se comparte.

El browser tiene varios mecanismos de storage: LocalStorage, SessionStorage, Cache API, IndexedDB, etc. Cada uno tiene un propósito pero por el momento no ahondaremos en eso, me enfocaré en que estos nos ofrecen persistencia a nivel dominio, lo cual es útil para poder tener datos que sean consistentes en todas la tabs abiertas en nuestra web en un navegador y en algunos casos poder hacer sincronización de datos con el servidor cuando por alguna razón perdemos la conexión o estamos en modo "offline".

Consideraciones

Ya vimos que tenemos varios storages para persistir datos, ¿y?. La persistencia en el browser involucra ciertas consideraciones que hay que tomar en cuenta para la estabilidad y el buen funcionamiento de nuestra web

Persistencia temporal

La data del browser (storage) puede ser borrada ya sea por el mismo browser o por el usuario. Esta consideración nos agrega un constraint.

En ningún momento des por hecho que va a existir data

Hay data que corresponde a operaciones sensibles, como un flujo de pagos que es preferible manejar la persistencia a nivel servidor y quizas solo persistir en el browser el resultado final porque la data podría ser borrada en cualquier momento, cosa que no pasaría en una base de datos en el servidor.

Limites y permisos

Si bien los equipos de computo tienen cada vez mas potencia, también es cierto que la exigencia a estos equipos es mayor y los recursos son limitados. A diferencia de un servidor donde como developers tenemos el poder absoluto del sudo (chiste linuxero). En el browser podríamos tener permisos o no, tener espacio o no. Para resolver estas preguntas tenemos el StorageManager API.

Esta API nos ofrece métodos como estimate que nos regresa una promesa que objeto con la quota (espacio máximo que podemos usar), usage (lo que hemos usado) y usageDetails.

Cada browser tiene sus políticas para el storage, la quota puede variar incluso la parte de permisos. También hay que mencionar que cada storage tiene también sus limitantes, esto nos deja otro constraint.

No asumas que toda la data que intentas guardar va a persistir

Si quieres saber mas del Storage y la persistencia, te recomiendo leer este artículo.

El storage manager tiene 2 métodos llamados persist y persisted que nos ayudan con la cuestion de permisos.

Nota: Los storage se categorizan en 2 "Best Effort" y "Persistent". Para mas detalles consulta este artículo. También te recomendamos esta referencia de como el browser administra las quotas.

Conclusiones

La persistencia involucra factores a tomar en cuenta como Permisos y Quotas. Y estos pueden ser determinados por las políticas de cada navegador y el dispositivo donde se ejecuta nuestra web.

¿Vale la pena saber esto? Claro, el tener conocimiento de estas APIs, sus beneficios y sus limitantes nos da herramientas para brindar una mejor experiencia a los usuarios y ellos son lo mas importante.

Sincronizando data entre tabs

Joel Humberto Gómez Paredes — Mon, 24 Jun 2024 01:10:26 +0000

Una de las cosas mas complicadas de entender y manejar en una aplicación es el estado de una aplicación. Aunque tenemos herramientas como Redux, Zustand o cualquier otra biblioteca JS que salga en los próximos minutos que te tome leer este post.

Pero este post no se trata de bibliotecas, se trata de la plataforma y como sincronizamos datos entre las diferentes tabs que pueden estar abiertas en el navegador.

El navegador administra la memoria de una tab de manera individual pero la capa de datos se administra por dominio. Tenemos varias alternativas para almacenar datos:

LocalStorage
Cookies
Cache API
IndexedDB
File System Access API

Hay muchas formas para almacenar datos y cada una de estas tiene un propósito. Ejemplo, la Cache API esta hecha para almacenar la respuesta de requests de red, lo cual nos sirve features como el modo offline.

Antes de hablarles de como sincronizar datos entre tabs, me gustaría dejar claro algunos puntos.

No hay mecanismo que el browser brinde de manera nativa una sincronización entre tabs.
No toda la información debe sincronizarse.
Normalmente usamos el servidor como fuente de la verdad y esta bien pero hacer multiples requests para tener la misma información que ya tienes en una tab me parece innecesario.

Para ello exploraremos 2 approaches:

LocalStorage
Cualquier Storage que uno quiera + Service Workers

LocalStorage

Esta opción es la menos recomendada porque es síncrona y ocupa el thread principal de ejecución de JS, pero siendo honestos es uno de los storages mas utilizados.

El objeto window tiene asociado un evento "storage", el cual se ejecuta cada vez que el storage cambia. Este se ejecutará en cada uno de nuestros tabs entonces con simplemente suscribirnos al evento podemos saber si algo cambió (se ejecuta en todos menos en el tab donde se ejecutó el cambio).

Vamos a hacer una página simple donde tengamos un contador y un botón para incrementar. El requerimiento es que cada vez que de click el contador se incremente se refleje en todas las tabs que tengamos abiertas.

Nota: Sugiero usar un folder y serve como servidor estático

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Sync local storage</title>
  </head>
  <body>
    <h1 id="counter">0</h1>
    <button id="increase">Increase</button>
    <script>
      document.getElementById("increase").addEventListener("click", () => {
        const counter = +localStorage.getItem("counter", 0) + 1;
        document.getElementById("counter").textContent = counter;
        localStorage.setItem("counter", counter);
      });
      window.addEventListener("storage", (event) => {
        if (event.key !== "counter") return;
        document.getElementById("counter").textContent = +localStorage.getItem(
          "counter",
          0
        );
      });
      window.addEventListener("load", () => {
        document.getElementById("counter").textContent = +localStorage.getItem(
          "counter",
          0
        );
      });
    </script>
  </body>
</html>

La parte importante de esta página es suscribirse al evento de cambio del localStorage.

 window.addEventListener('storage', (event) => {
      if (event.key !== 'counter') return;
      document.getElementById('counter').textContent = +localStorage.getItem('counter', 0);
    });

El evento storage tiene una propiedad llamada key, mediante la cual podemos saber que cambió, este paso es crucial porque el storage es solo uno. Entonces esta al alcance de extensiones o cualquier otro script que se ejecute en el contexto de la aplicación. En este evento podríamos poner dispatchers o lo que queramos que reflejo el cambio que queremos a nuestro state manager.

La ventaja de este approach es que es fácil, ya tenemos un sistema de eventos incluido que evita la redundancia (evita disparar el evento en la tab donde se ejecutó)

La desventaja ... es el localStorage, todos tienen acceso y es síncrono, además de que solo puedes guardar strings así que debes hacer parseos para guardar estados complejos y si quieres ejecutar acciones solo para ciertas partes de tu state manager tendrás que verificar que solo se disparen cambios si la data cambió (algunos state managers ya incluyen esta funcionalidad).

Cualquier Storage + Service Workers

Este approach es un poco más complicado pero en lo personal lo prefiero, por la simple y sencilla razón de que no es el local storage.

Para esto necesitamos una pieza de software centralizada que actue como un pubsub para la administración de eventos. En este caso usaremos un service worker ya que es una instancia compartida por todas las tabs (clients).

Las tareas del service worker serán las siguientes:

Suscribirse a un evento que nos diga que se quiere hacer un incremento
Hacer un update en nuestra base de datos (en este caso usaremos indexeddb)
Mandar un evento que le indique a todos los tabs(clients) que hubo un incremento.

Este service worker cumple con ese objetivo

self.addEventListener('message', (event) => {
  if (event.data === 'request_increment') {
    incrementValueInDB();
  }
});

function incrementValueInDB() {
  const request = indexedDB.open('APPDB', 1);

  request.onupgradeneeded = function(event) {
    const db = event.target.result;
    db.createObjectStore('count', { keyPath: 'id' });
  };

  request.onsuccess = function(event) {
    const db = event.target.result;
    const transaction = db.transaction(['count'], 'readwrite');
    const objectStore = transaction.objectStore('count');
    const request = objectStore.get(1);

    request.onsuccess = function(event) {
      let count = event.target.result?.count || 0;
      count++;
      const requestUpdate = objectStore.put({ count, id: 1 }, 1);
      requestUpdate.onsuccess = function() {
        self.clients.matchAll().then((clients) => {
          clients.forEach((client) => client.postMessage('has_increment'));
        });
      };
    };
  };
}

El primer paso consiste en suscribirse a los mensajes y filtrarlos, ya que al ser una instancia compartida muchos mensajes pueden llegar.

self.addEventListener('message', (event) => {
  if (event.data === 'request_increment') {
    incrementValueInDB();
  }
});

La segunda parte es el código donde se actualizará la base de datos. Los service workers tienen acceso a IndexedDB así que ahí hacemos el incremento (aquí depende de la API que quieran usar, por eso no hay código)

La tercera parte consiste en avisar a los demas que hubo un incremento.

self.clients.matchAll().then((clients) => {
          clients.forEach((client) => client.postMessage('has_increment'));
        });

Listo, con esto terminamos el service worker y ahora les comparto el código del HTML/JS

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Sync local storage</title>
  </head>
  <body>
    <h1 id="counter">0</h1>
    <button id="increase">Increase</button>
    <script>
      document.getElementById("increase").addEventListener("click", () => {
        navigator.serviceWorker.controller.postMessage('request_increment');
      });

      if ("serviceWorker" in navigator) {
        window.addEventListener("load", function () {
          const request = indexedDB.open('APPDB', 1);

          request.onupgradeneeded = function(event) {
            const db = event.target.result;
            db.createObjectStore('count', { keyPath: 'id' });
          };

          request.onsuccess = function(event) {
            const db = event.target.result;
            const transaction = db.transaction('count', 'readwrite');
            const store = transaction.objectStore('count');
            const getRequest = store.get(1);

            getRequest.onsuccess = function(event) {
              const data = event.target.result;
              const count = data ? data.count : 0;
              document.getElementById('counter').textContent = count;
            };
          };
          navigator.serviceWorker.register("/sw.js").then(
            function (registration) {
              navigator.serviceWorker.addEventListener('message', function(event) {
                if (event.data === 'has_increment') {
                  const request = indexedDB.open('APPDB', 1);
                  request.onsuccess = function(event) {
                    const db = event.target.result;
                    const transaction = db.transaction('count', 'readwrite');
                    const store = transaction.objectStore('count');
                    const getRequest = store.get(1);
                    getRequest.onsuccess = function(event) {
                      const data = event.target.result;
                      const count = data ? data.count : 0;
                      document.getElementById('counter').textContent = count;
                    };
                  };
                }
              });
            },
            function (err) {
              console.log("ServiceWorker registration failed: ", err);
            }
          );
        }); 
      }
    </script>
  </body>
</html>

En la aplicación el código mas importante es la parte de enviar el evento de incrementar

document.getElementById("increase").addEventListener("click", () => {
  navigator.serviceWorker.controller.postMessage('request_increment');
});

Y suscribirnos al evento "has_increment" para tomar el dato del local storage

navigator.serviceWorker.addEventListener('message', function(event) {
                if (event.data === 'has_increment') {
                  const request = indexedDB.open('APPDB', 1);
                  request.onsuccess = function(event) {
                    const db = event.target.result;
                    const transaction = db.transaction('count', 'readwrite');
                    const store = transaction.objectStore('count');
                    const getRequest = store.get(1);
                    getRequest.onsuccess = function(event) {
                      const data = event.target.result;
                      const count = data ? data.count : 0;
                      document.getElementById('counter').textContent = count;
                    };
                  };
                }
              })

Nota: Si quieres hacer alguna modificación se cauteloso porque los service workers son difíciles de depurar

La ventaja de este enfoque es que no se bloquea el main thread de JS ya que la parte de actualización de datos se hace directamente en el worker y que es hasta cierto punto agnóstica ya que podemos usar cualquier store accesible por un worker.

La desventaja es que tiende a ser un poco complicado

Conclusión

Ambos enfoques funcionan, dependerá de la arquitectura de la aplicación el decidir cual usar

Camino a ser experto en web performance - Performance budgets

Joel Humberto Gómez Paredes — Mon, 25 Mar 2024 03:36:44 +0000

En un post anterior hablamos sobre la cultura del performance, esta es la continuación donde hablaremos de como esa cultura se convierte performance budgtes.

Performance budgets

Los performance budgets son presupuestos que tenemos para que nuestra web pueda operar. Exacto, PRESUPUESTOS; como en las finanzas personales (al menos las sanas) uno establece presupuestos al hacer compras como televisiones, autos, despensa (comida del mes), salidas por la noche, figuritas y coleccionismo (no tengo finanzas sanas con las figuritas XD).

Budget hace alusión a presupuesto pero en la realidad puede ser manejado como un contrato, límite o incluso como una meta.

Como todo presupuesto, puede crecer o reducir dependiendo de lo que se necesite y no se acumula (eso es ahorro). En el desarrollo web del día a día esto no nos preocupa para nada, lo mas cercano a presupuesto que nos preocupa es la cuenta de nuestro proveedor de la nube.

¿Cómo defino estos performance budgets? Bueno, a diferencia de nuestras finanzas personales estas son un poco mas complejas (creo). Debido a que los performance budgets involucran una serie de métricas que están relacionadas con todo aquello que afecta nuestra web (y pueden chocar entre si). Estas métricas están agrupadas en 3 grupos:

Milestone timings ⏱️
Quantity-based metrics ⚖️
Rule-based metrics 💯

Milestone timings ⏱️

Métricas definidas por eventos en el browser (como DOMContentLoaded). Todas estás métricas tienen como base intervalos de tiempo

Estas pueden medirse usando directamente desde la API del browser. Pueden ser una combinación de varios eventos o pueden ser eventos que involucren alguna interacción con el usuario y que tán rápido este obtiene una respuesta a esa interacción.

Un ejemplo son las metricas centradas en el usuario o core web vitals.

Es un tema bastante extenso que aborademos en otros posts

Quantity-based ⚖️

Métricas definidas por el tamaño o cantidad de los assets/recursos que usas en tu web. Cuando se trata de tamaño normalmente usamos kilobytes o megabytes.

Todo aquello que afecta a la carga de tu web: Documents, estilos externos, imágenes, scripts y bibliotecas de terceros.

Es un tema bastante extenso que aborademos en otros posts

Rule-based 💯

Métricas definidas por herramientas de auditoria como lighthouse.

Lighthouse puede auditar varios aspectos de una aplicación como accesibilidad pero nos enfocaremos en performance

Usando como ejemplo lighthouse, una de sus métricas se llama performance score. Esta se define por un conjunto de buenas prácticas definidas en la industria y su estado actual. Revisa esta tool llamada Lighthouse Scoring Calculator para que conozcas mas acerca de esto)

Ya se la saben, tema extenso. Se va para mi backlog de posts

De un objetivos a performance budgets

En posts anteriores hablamos sobre que debemos estar alineados por ciertos objetivos que todo el equipo entienda. Estos objetivos serán la base de nuestros budgets.

Nuestra página principal debe cargar en 2.5 segundos o menos, en dispositivos móviles de gama media con una conexión 3G normal

De este objetivo podemos definir algunos budgets

En métricas Milestone timings podemos definir el siguiente budget:

El Largest ContentFul Paint(LCP) de la página principal debe ser menor de 2.5 segundos
El First ContentFul Paint(FCP) de la página debe ser menor a 2s

En métricas Quantity-based es un poco mas complejo ya que debemos tomar en cuenta la velocidad de la red ya que eso nos dice cuanta información se puede transmitir. Esa sería nuestra base para el budget

Tomando en cuenta que una conexión 3g normal, le descarga es de descarga 780kilobits por segundo, en 2.5 segundo podemos descargar tenemos 1950 kilobits, esto expresado en kilobytes serían un poco mas de 240kb (243.75)

Por ende la suma de todos tus assets no debe pasar de este peso o ninguno de tus assets debería pesar mas de lo que puedes transferir (puede haber excepciones)

Y a partir de eso podemos definir los budgets para cada uno de los assets que ocupamos en nuestra página. En este caso vamos a usar performancebudget.io para empezar a hacer ese budget.

Selecciona en tipo de metricas assets
Selecciona la velocidad de conexión (3G Slow de 780kb)
Escribe la velocidad en segundos(2.5)
Modifica los valores que se adapten a lo que necesites

En esta parte del proceso tendremos algo similar a esto

En el siguiente paso se nos muestra un resumen de nuestro budget

Ademas del tiempo de descarga estimada para otras velocidades de red

Finalmente puedes descargarlo en un formato que es compatible con lighthouse-ci (explicaré esto en un post dedicado a auditorias)

[
  {
    "resourceSizes": [
      {
        "resourceType": "document",
        "budget": 6
      },
      {
        "resourceType": "stylesheet",
        "budget": 7.8
      },
      {
        "resourceType": "script",
        "budget": 39.6
      },
      {
        "resourceType": "image",
        "budget": 151.2
      },
      {
        "resourceType": "media",
        "budget": 23.4
      },
      {
        "resourceType": "font",
        "budget": 12
      }
    ],
    "timings": []
  }
]

En un lenguaje mas humano podemos decir que:

La página principal debe cargar 6kb de html o menos
La página principal debe cargar 7.8kb de css o menos
La página principal debe cargar 39.6kb de JS o menos
La página principal debe cargar 151.2kb de imagenes o menos
La página principal debe cargar 23.4kb de recursos multimedia o menos
La página principal debe cargar 12kb de fuentes o menos

Listo ya tenemos nuestros budgets en terminos de Quantity-based

En métricas Rule-based podemos ir a lighthouse scoring calculator y definir nuestro budget, seleccionando la versión de Lighthouse (10) y el tipo de target (mobile). En este caso nuestro budget es una combinación de métricas (algunas que definimos ya en milestone timings)

Al agregar el límite máximo de nuestros budgets a lighthouse podemos ver el score aproximado que deberiamos de tener, en este caso: 93.

Y finalmente con todo esto podemos tener nuestro budget:

El score en performance de la página principal debe ser al menos de 93% en lighthouse

Este es un ejemplo de budget que podría ser visto como una meta que fija un límite para ir hacia adelante.

Dificultad al definir budgets

Una de las partes complejas de crear budgets es entender que estos pueden estar relacionados y el modificar uno puede presentar un side-effect en otro.

Ejemplo el FCP y el LCP, si tu HTML y CSS que necesitas para renderizar tu aplicación sobrepasan 240kb y tu budget es para conexión 3G vas a tener problemas.

Si tus métricas tienen que ver con TTI, INP o FID pero tienes un uso excesivo de JS, tendrás problemas.

Es por ello que los performance budgets deben partir de objetivos alineados a tu negocio donde el foco este en la experiencia de los usuarios que te generen mejor revenue, tomando en cuenta las condiciones de estos como base.

Puedes optimizar para conexiones 3G y los usuarios con 4G tendrán un sitio más rápido. Si la experiencia es buena en conexiones lentas, podría ser mejor para conexiones rápidas o no? No necesariamente

Si bien la rápidez es parte clave del performance, no solo se necesita ser rápido sino también usable. Podríamos hacer que un sitio web cumpla con todas las métricas que estableciamos agregando delay de recursos, reduces el tiempo de carga pero podrías aumentar el tiempo en que al usuario le toma hacer lo que necesita.

Es importante recordar que no todas las métricas de una web deben tener un budget solo las significativas para tu negocio.

También hay algunos performance budgets que se establecen en base a lo que tu competencia tiene (ya se la saben XD)

Siguientes pasos

Una vez que ya definimos nuestros budgets (no necesariamente se hace en este orden). Lo que sigue es usarlos para auditar nuestras aplicaciones. Eso queda fuera del scope de este post pero voy a dar un adelanto.

Así como la pirámide del tests hay auditorias de performance que se realizarán dependiendo del ambiente(stage) de la aplicación. Para obtener feedback lo más rápido posible sin tener que llegar al stage de producción.

Un budget es una descripción que nos guía a una implementación

Hay algunos bundlers como webpack que tiene ciertas configuraciones de performance pueden servirnos en ambiente local para cuidar el tamaño de cierto tipo de assets.

Bundlesize es una tool que nos puede ayudar en CI como gatekeeper para cuidar que nuestros performance budgets de tipo Quantity se cumplan.

Lighthouse-ci nos puede ayudar para realizar auditorias de performance budget de tipo rule-based pero también de milestone timings y quantity. En un ambiente CI pero también en ambientes de Quality Assurance.

Y un overview de herramientas más robustas como webpagetest, calibre, speedcurve, entre otras. Espero les haya gustado, de ser así compartan, comenten y reaccionen, no va a pasar nada si no lo hacen pero sería genial :D

Camino a ser experto en web performance - Cultura del Performance

Joel Humberto Gómez Paredes — Tue, 19 Mar 2024 06:12:30 +0000

Bueno el día de hoy marca un hito en mi carrera profesional como frontend ya que he decidido dar un paso adelante y especializarme en web performance.

Como parte de eso voy a estar compartiendo una serie de posts que ignoro cuantos sean, solo se que será al menos 1 a la semana con mis aprendizajes en este camino ninja.

Como frontends tenemos que saber muchas cosas acerca de performance:

Loading performance
- Diferencias entre protocolos HTTP1 y HTTP2
- Prioridad de descarga de los recurso
- Prefetch, Preload y Preconnect
Rendering performance
- Recursos render blocking
- Recursos parsing blocking
- Critical rendering path
El costo de JS y el procesamiento de ciertos assets
Core Web Vitals
Real User Monitoring

Probablemente manejes muchos de estos temas y aunque sepas esto, si el performance no es un punto clave del producto en tu organización, no podrás aplicar ese conocimiento para generar un impacto significativo. Para que esto pase debe existir la cultura del performance.

Cultura del performance

Una de las cosa mas geniales de trabajar en un producto es el enfoque, todos miran en la misma dirección y es mucho más fácil cumplir metas cuando toda la organización esta alineada.

El tema de performance normalmente es visto como una actividad asociada al equipo de ingeniería/desarrollo. Si bien la implementación de estrategias recae en ese equipo, se debería involucrar a todos los actores que marcan el rumbo del producto como: Enginer Managers, Designers, Project Managers, etc.

Tomar al performance como una pieza clave para cumplir la metas del negocio. Esta es la cultura del performance.

En un equipo la cultura es importante ya que nuestras acciones son guiadas por la antes esta. Como en los sistemas de diseño, la mayor parte no recae en la implementación, sino en la comunicación, adopción y contribución.

¿Cómo comunico que esto es importante?
¿Cómo alinear al equipo?
¿Cómo los miembros del equipo pueden contribuir?

Responder estas preguntas parece simple pero en la práctica te encontrarás con problemas de varias indoles como:

Excepticismo (no creemos que eso ayude)
Silos (equipos aislados y no colaboran)
Falta de apoyo o de "ownership" de tareas asociadas al performance (hay cosas más importantes)

Generar una cultura es complicado, costoso (es una inversión) y mas que nada una tarea de nunca acabar porque aunque tengas ciertas métricas para medir performance, estas pueden ir cambiando de acuerdo a las necesidades del negocio (imagina que tu app es desktop pero te piden dar soporte a resoluciones mobile).

¿Cómo comunico que esto es importante?

DINERO, si, DINERO.

El performance esta relacionado con la UX, la UX tiene relación con: convertion, retention, revenue, etc. Esto lo pueden entender personas de marketing, management y development.

Una comunicación es más efectiva cuando se lleva a cabo en términos que todos entendamos. Creo que todos entendemos que sin dinero una empresa no puede operar y entre más genere puede invertir más en su visión y su misión.

También podemos dar justificaciones mas técnicas de acuerdo a ciertos tipos de perfiles o departamentos. Esto al alcance de una busqueda en Google o en WPO Stats.

Ejemplo:

Nuestro sitio web gastoinnecesario.com tarda 5 segundos en cargar

Esto no me dice mucho, pero si presentas un caso de estudio como AutoAnything reduced page load time by 50% and saw an 12-13% increase in sales o un artículo de la importancia de la velocidad.

Es más fácil de comunicar los beneficios de incluir el performance como parte del producto.

¿Cómo alinear al equipo?

Una vez que entendemos los beneficios nos toca pensar como estamos alineados.

Eso lo logramos a traves de los performance budgets.

Los performance budgets son acuerdos, es un presupuesto que los involucrados en el producto deben respetar. Es algo que hace más fácil entender y tomar en cuenta el impacto de las decisiones que se toman ya que hay un límite definido.

"Deciding a page can’t exceed 500kB when a mock-up containing three carousels and a full-screen high-resolution background image has already been approved isn’t going to do you much good" - Tim Kadlec

No todos los performance budgets son exclusivos de ingeniería, a nivel implementación nosotros podemos representarlos en cierto formato pero al final los budgets son presupuestos entendibles para todos expresados en texto comprensible. Ejemplo:

Nuestra página principal debe cargar en 2.5 segundos o menos, en dispositivos móviles de gama media con una conexión 3G normal

Esto hace que cada perfil piense que puede hacer para respetar ese presupuesto.

Este budget me dice que bajo ciertas condiciones el tamaño de los assets que ocupa la página no puede ser mayor de lo que se puede transmitir en ese periodo de tiempo.

No voy a ahondar mucho en esto, porque ya tengo en mente otro posts donde abordaré esto de manera mas profunda (probablemente sea otra serie). Pero si quieres entrarle al chisme te recomiendo este artículo de Addy Osmani

¿Cómo los miembros del equipo pueden contribuir?

Honestamente no importa que tanto tiempo dediques a esto no es suficiente, debes tener: advocates, embajadores, champions, colaboradores, etc.

Por eso es importante que el primer punto quede muy claro, eso hará que todos nos alineemos y se designe tiempo para dedicarlo a performance.

También hay que generar documentación sobre donde encontrar los performance budgets, las herramientas que se van a utilizar, en que partes del proceso se harán auditorias de estos budgets y en que casos se pueden hacer excepciones.

Como toda iniciativa hay que reducir la fricción, honestamente creo que nadie estaría de acuerdo con tener una aplicación con bajo performance, pero a veces hay ciertas features que pueden ser críticas y probablemente sean más importantes que tener un desempeño optimo. Si dejamos claro cuando podemos modificar el budget o hacer excepciones es más simple que las personas se sumen.

En otros posts veremos como definir performance budgets y los tipos de métricas, espero les haya gustado y puedan compartir.

CSS @layer: ¿Héroe o amenaza?

Joel Humberto Gómez Paredes — Mon, 18 Mar 2024 05:04:11 +0000

La vida del developer es una vida donde siempre vas a estar aprendiendo. Ya sea por los cambios constantes del mercado, la organización, nuevas tools que te ayudan a hacer mejor tu trabajo, nuevas features que se remueven/agregan a la plataforma o alguna IA que te va a robar el trabajo (saludos al Devin XD)

Hoy vamos a hablar de @layer, una regla de CSS que viene a resolver uno de los tantos "problemas" que podemos tener en la creación de estilos ... "LA ESPECIFICIDAD".

En si no hay ningún problema pero cuando manejamos aplicaciones grandes es complicado manejar la especificidad. Si bien podemos usar metodologías para organizar nuestro CSS y controlar el origen y la especificidad; hay una pieza faltante que esta regla puede resolver ... definir la prioridad (sin usar !important) de manera consistente.

CSS at-rule @layer

@layer esta en baseline desde 2022, aunque en algunos Browsers de Android se agregó hasta marzo de 2024 (según caniuse).

Antes de continuar, quiero que hagamos 2 cosas simples:

Cada vez que te veas el texto "Atinale al color", lee el código y responde cual color será el del elemento.
Realiza el ejercicio y verifica la respuesta.

Para mi es como un juego, te podría sorprender y ciertamente hará esto menos aburrido.

Ahora si, haremos varios mini demos simples pero inquebrantables.

Primero crea un index.html con el siguiente contenido

<html>
  <head>
      <link rel="stylesheet" href="layer.css">
  </head>
  <body>
    <main class="main" />
  </body>
</html>

Y ahora vamos crear un archivo layer.css y agregar el siguiente código

@layer {
  .main {
    background: blue;
  }  
}

.main {
  height: 50px;
}

Atinale al color

SPOILER ALERT

..........

Creo que estuvo fácil o quizás no, es azul.

Y si cambias por este código?

@layer theme {
  .main {
    background: blue;
  }  
}

.main {
  height: 50px;
}

Atinale al color

SPOILER ALERT

..........

Esto es juego de niños, es azul.

Ahora, un poco de explicación teoría aburrida. @layer es una CSS at-rule, quiere decir que esta internamente tiene un bloque de código y esta puede tener un nombre o no tenerlo.

Y si cambias por este código?

@layer theme {
  .main {
    background: blue;
  }  
}

@layer dummy {
  .main {
    background: red;
  }  
}

.main {
  height: 50px;
}

Atinale al color

SPOILER ALERT

..........

Too easy, es rojo, seguramente te estas replanteando que haces aún aquí leyendo esto, vamos hacerlo más interesante. Cuando usas @layer, las declaraciones posteriores siempre tendrán mas prioridad que las primeras.

@layer theme {
  main.main {
    background: blue;
  }  
}

@layer dummy {
  .main {
    background: red;
  }  
}

.main {
  height: 50px;
}

Atinale al color

SPOILER ALERT

..........

Probablemente si nos basamos en la espeficidad tu respuesta fue azul, pero la regla @layer lo que predomina es el orden no la especificidad, incluso si agregaras un id en el selector del layer theme funcionaría igual (hazlo para que veas que no te miento).

Here we go again

@layer theme {
  .main {
    background: blue !important;
  }  
}

@layer dummy {
  .main {
    background: red;
  }  
}

.main {
  height: 50px;
}

Atinale al color

SPOILER ALERT

..........

Recuerden, la cascada es la que determina que estilos se aplican. En esta se toma en cuenta la ubicación y la importancia. En este caso la @layer theme aplica un estilo con !important, eso hace que el orden e incluso la especificidad no importen.

Esto se puso mas interesante

@layer theme {
  .main {
    background: blue !important;
  }  
}

@layer dummy {
  .main {
    background: red !important;
  }  
}

.main {
  height: 50px;
}

Atinale al color

SPOILER ALERT

..........

Seguro pensaste que era rojo, yo también lo pensé pero al parecer una layer que aplique un estilo con !important prevalecerá sobre otro que venga después, sin importar la especificidad. Es por eso que @layer puede ser héroe o villano. Aunque si usas layers, el uso de !important debería estar prohibido.

Esto se puso interesante

@layer dummy, theme;

@layer theme {
  .main {
    background: blue;
  }  
}

@layer dummy {
  .main {
    background: red;
  }  
}

.main {
  height: 50px;
}

Atinale al color

SPOILER ALERT

..........

@layer se puede declarar e inmediatamente colocar un bloque o puede declararse y posteriormente definir el bloque. El orden en que se definan le dara la prioridad. Recuerda las primeras siempre tendrán menos priordad que las últimas. Por ende el color es azul, aunque solo se hubiera puesto @layer dummy; hubiera dado el mismo resultado

Vamos con otro, ya casi llegamos al final

@layer theme {
  .main {
    background: blue;
  }  
}

@layer dummy {
  main.main {
    background: red;
  }  
}

.main {
  background: green;
  height: 50px;
}

Atinale al color

SPOILER ALERT

..........

Y el color es ...

Verde. Los estilos fuera de las capas tienen mayor prioridad que las que tienen capas, incluso aunque pusieras la declaración de estilos antes de la declaración de @layer tendría exactamente los mismos efectos, a menos que usaras !important. Lo cual agrega mayor prioridad, vamos intentalo.

Ok, ya estamos cerca del final, este es el último mini demo, respira hondo, vacia tu mente, deja que tu mente fluya por la cascada, se la cascada

@layer dummy, theme;

@layer theme {
  .main {
    background: blue !important;
  }
}

@layer dummy {
  main.main {
   background: red;
  }
}

main.main {
  background: green !important;
  height: 50px;
}

Atinale al color

SPOILER ALERT

..........

Casi podría apostar que pensaste que era verde, es mas si lo pensaste mandame un tweet, mencioname en un post o lo que mas te agrade y pon "Yo también pensé que era verde". Pero es azul, recuerda !important define prioridad, pero cuando 2 estilos son importantes el origen de donde se declara tiene más relevancia.

Cada @layer puede tener incluso nested layer pero no abordaremos ese tema en este momento, porque ya me extendí y hay algo muy importante que debo decirte antes.

Bueno ahora la parte mas importante de este post, no es seguro usar este feature de momento si mantienes una misma base de código o estilos para mobile :(

Si bien esta disponible desde 2022, si una buena parte de tu mercado es Android probablemente no sea buena idea usarla, revisa caniuse y el tipo de usuarios que llegan a tus aplicaciones para saber si es seguro usarla.

En este caso @supports no nos va a servir, porque esta solo evualua si un estilo es válido no tiene soporte para at-rules. Este soporte esta en discusión, así que mientras tanto el uso de @supports at-rule(@layer) tiene un futuro incierto.

Podríamos usar Javascript para saber si tiene soporte

if (typeof CSSLayerBlockRule !== 'undefined') {
  console.log("Si tenemos soporte :D");
}

Pero esto solo agregaría un blocker mas al parsing y al rendering, ademas de tener que generar estilos que soporten @layer y un fallback que no, mucha arquitectura que podría no valer la pena. Pero como dije, todo dependerá de nuestros usuarios.

Gracias por llegar hasta aquí, te dejo un pen con un código similar al del último mini demo, si puedes comparte y espero que hayas aprendido algo (aunque no vayas a usar esta feature)

@supporting lo insoportable en tu CSS

Joel Humberto Gómez Paredes — Sat, 16 Mar 2024 09:13:14 +0000

Con el paso del tiempo los major browsers han estado agregando soporte a varias features de CSS, lo cual es bastante genial :D ... pero, siempre hay un pero. Es complicado que todos se pongan de acuerdo y liberen las mismas features importantes a la vez, además de que es prácticamente imposible que todos nuestros usuarios tengan su browser actualizado en todo momento.

En CSS es complicado seguir una estrategía multi-target bundle (En resumen definir un baseline para con un bundle legacy y uno "moderno"). Ya que no tenemos en el tag link un atributo similar a nomodule del tag script. Adémas de que este approach poco a poco dejará de ser usado porque cada vez son menos los browsers donde valga la pena dar ese soporte.

Actualmente lo que hacemos es usar una estrategia de fallbacks para resolver este problema (parcialmente). Definimos un baseline y usando browserslist e incluimos plugins de PostCSS u otras tools que agregarán los fallbacks o mantendrán intactor el código dependiendo de si la feature que usamos tiene soporte o no en el baseline definido.

Aún así es complicado soportar ciertas features de CSS modernas o no estandarizadas porque solo sabemos si el soporte existe en tiempo de ejecución y la estrategia mencionada anteriormente se realiza en tiempo de compilación.

Antes usabamos Modrnizr pero JS es parse blocking y tendríamos el mismo problema para features nuevas.

Para esto podemos usar algo que en CSS se llama Feature queries, que al igual que los media queries, son una forma de definir un grupo de reglas basado en ciertas condiciones.

Para esto usamos la regla @supports, esta lo que evalua es que la condición sea válida y solo eso (caniuse nos respalda XD).

@supports <condicion> {
  /* Tu CSS va aquí */
}

Esto no es nada nuevo, igual y este post no te aporta nada pero vamos a tratar de que lo haga. Con un caso práctico que me sucedio recientemente: Las nuevas unidades del viewport.

Soy fan del min-height: 100vh pero esta regla no da los resultados deseados en dispositivos móviles debido al comportamiento de la UI, por ejemplo la toolbar que se agrega en la parte de abajo en dispositivos iOS en Safari.

Según caniuse esta feature esta desde noviembre del 2022 en major browser pero en Android Browser(chromium) se libreró febrero de 2024.

Ahora vamos a lo bueno, un mini demo. Haremos algo simple, que una página tenga el 100% del viewport, algo común pero muy significativo.

Comenzamos creando un index.html con el esqueleto de la página

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <link rel="stylesheet" href="styles.css">
  <title>Viewport</title>
</head>
<body>
  <main class="main" />
</body>
</html>

Creamos nuestro archivo styles.css. Como primer paso usaremos vh y después agregaremos el soporte.

html, body {
  margin: 0;
  padding: 0;
}

.main {
  background-color: #ffdd00; /* Si, es el color del super saiyajin */
  min-height: 100vh;
}

Si pruebas esto en un iphone, lo mas probable es que tengas un horrible scroll.

Ahora vamos a agregar el soporte para usar un min-height: 100dvh pero usando custom properties para no tener que recordar el selector y compartir esto usando la cascada.

Luciría así

html, body {
  margin: 0;
  padding: 0;
}

:root {
  --page-height: 100vh;
}

@supports (min-height: 100dvh) {
  :root {
    --page-height: 100dvh;
  }
}

.main {
  background-color: #ffdd00;
  min-height: var(--page-height);
}

Ahora si pruebas en un dispositivo iOS o similar, ese scroll debería haber desaparecido.

Bueno, vamos a explicar paso por paso. Siguiendo una estrategia estilo progressive enhancement, lo primero que se hace es definir una custom property --page-height en el selector :root con el valor base que debería tomar para representar el alto mínimo de una página.

:root {
  --page-height: 100vh;
}

Ahora usaremos supports para asignar el valor a 100dvh a nuestra custom property --page-height.

La sintaxis me pide evaluar una condición y esta debe ir entre paréntesis, esta condición es formada por <propiedad>: <valor> (un estilo). Si el estilo es válido la evaluación es verdadera y si no es falsa.

@supports (min-height: 100dvh) {
  :root {
    --page-height: 100dvh;
  }
}

Si dvh no existe como unidad, este bloque jamas se ejecutará porque no sería un estilo válido.

Y al final simplemente usamos la custom property que definimos:

.main {
  background-color: #ffdd00;
  min-height: var(--page-height);
}

Recomiendo que sigas el ejemplo que hicimos pero si quieres también te dejo un código similar en codepen. Aunque te recomiendo descargarlo y ejecutarlo en tu maquina porque en los codepen se ejecuta en un iframe (probablemente debí guardarlo en otro lado pero ya estaba ahí XD)

Gracias por llegar hasta aquí si puedes da like y comparte :)