Bitácora: cómo se construyó La Trastienda Web y cuánto pesa cada página

Un sitio que explica cómo se construyen las webs debería poder enseñar su propia trastienda. Esta bitácora recoge las decisiones tomadas al montar La Trastienda Web, lo que se descartó y por qué, y una tabla con el peso de cada tipo de página. La tabla la genera el propio programa que construye el sitio, así que se actualiza sola con cada publicación.

El punto de partida

Los requisitos eran pocos y concretos. El sitio iba a publicar artículos largos, con tablas, fragmentos de código y diagramas; no necesitaba comentarios, cuentas de usuario ni tienda. Tenía que leerse bien en un móvil modesto, porque buena parte de las visitas llega desde el teléfono, y tenía que dejar sitio a la publicidad sin que los anuncios empujaran el texto al cargarse.

Con esas condiciones, la pregunta de la plataforma tenía una respuesta clara. En el artículo ¿Sitio estático o WordPress? se detalla la ruta de decisión general; aplicada a este caso, todo apuntaba al estático: un único editor, contenidos que cambian poco una vez publicados y ninguna función que necesite un servidor que ejecute código en cada visita.

Decisiones y descartes

Cómo funciona el generador

Cada artículo es un archivo HTML con una cabecera de datos en JSON: título, descripción, sección, fecha, imagen, fuentes y una nota de método. El generador lee esos archivos y produce las páginas completas con la misma plantilla. En el camino hace varias cosas que, hechas a mano, acaban fallando tarde o temprano:

• Pone un id a cada subtítulo y construye el índice del artículo a partir de ellos.
• Escribe la etiqueta canonical, los datos estructurados (Article y BreadcrumbList) y las etiquetas Open Graph con los mismos título, fecha e imagen que se ven en la página, para que no haya discrepancias entre lo visible y lo declarado.
• Genera sitemap.xml con la fecha de modificación real de cada artículo (la de publicación, o la de actualización si la hay), sin campos que Google ignora.
• Repasa todas las páginas producidas y avisa si encuentra un enlace interno roto, una imagen sin texto alternativo o una página con más o menos de un h1.

Las comprobaciones automáticas sólo detectan errores mecánicos. Que el generador termine «sin avisos» no dice nada de si un umbral está bien citado o si un ejemplo se entiende; eso se revisa leyendo, según la política editorial.

El peso de cada página

La tabla siguiente la rellena el generador midiendo los archivos que acaba de escribir. Son bytes sin comprimir: el servidor normalmente los envía comprimidos con gzip o Brotli, así que lo que viaja por la red es menos, sobre todo en HTML, CSS y SVG, que son texto.

Para ponerlo en contexto: en el artículo sobre presupuestos de rendimiento se calcula cuánto peso crítico cabe en una conexión móvil lenta si se quiere un LCP por debajo de 2,5 segundos. Las páginas de este sitio están muy por debajo de ese margen porque no cargan fuentes, frameworks ni JavaScript propio. Eso deja hueco para lo que sí pesará: los scripts de anuncios, que no controlamos y que se sumarán cuando la publicidad esté activa.

Cómo repetir esta medición en tu sitio

No hace falta un generador propio para obtener una tabla parecida. Con las herramientas para desarrolladores del navegador basta: abre la página en una ventana privada, pulsa F12, ve a la pestaña «Red» (Network), marca «Desactivar caché» y recarga. Al pie de la lista aparecen dos cifras: los datos transferidos (comprimidos) y los recursos (sin comprimir). La segunda es la comparable con la tabla de arriba.

Para separar lo propio de lo ajeno, escribe en el filtro el nombre de tu dominio y luego invierte el filtro (en Chrome y Edge, la casilla «Invertir»). Lo que queda son peticiones de terceros: analítica, anuncios, vídeos incrustados, widgets sociales. En muchos sitios esa segunda lista pesa más que la primera, y es la que menos se mira.

1. Anota el peso total y el número de peticiones con la caché desactivada.
2. Repite con la caché activada para ver qué se reutiliza entre páginas.
3. Filtra por tipo (JS, CSS, imágenes, fuentes) y apunta cada subtotal.
4. Guarda la fecha y la URL: sin eso, dentro de tres meses no podrás comparar.

Estas cifras miden peso, no velocidad. Para saber si la página se percibe rápida hacen falta métricas como LCP e INP, y a ser posible datos de visitas reales; la diferencia se explica en Cómo montar un experimento web.

Anuncios sin saltos de diseño

El objetivo de financiar el sitio con publicidad condiciona el diseño desde el principio, no al final. Un anuncio que llega tarde y empuja el párrafo que estás leyendo es la causa típica de un CLS alto. La solución recomendada en web.dev es reservar el espacio antes de que llegue el anuncio, así que la plantilla tiene huecos con altura mínima fija en lugares concretos y no en medio de tablas o listas.

Mientras la publicidad no esté activada, esos huecos no se imprimen: el generador sólo los incluye si en la configuración del sitio hay un identificador de editor de AdSense. Lo mismo pasa con el script de Google y con el archivo ads.txt. Así no se publican espacios vacíos ni se carga código que no hace nada.

Lo que queda pendiente

• Comprobar en el dominio publicado que http://, https:// sin www y las URL sin barra final redirigen con 301 a la versión canónica.
• Verificar que una URL inexistente devuelve un 404 real y no una página de error con código 200.
• Dar de alta el sitio en Search Console y enviar el sitemap; enviarlo no garantiza que se indexe todo, sólo ayuda a descubrir las URL.
• Recoger datos de campo de Core Web Vitals cuando haya tráfico suficiente para que aparezcan en el informe, y añadirlos aquí con su fecha.
• Repetir la tabla de pesos cuando los anuncios estén activos, separando lo que es del sitio de lo que añaden terceros.

Cada vez que se cierre uno de estos puntos, esta bitácora se actualizará con la fecha y el resultado.