La majoria de webs no necessiten un framework

La paradoxa de la velocitat

La indústria web ha convertit construir un lloc web en un problema d'enginyeria. Frameworks, bundlers, transpilers, runtimes: capes i capes de tecnologia que prometen fer les coses més ràpides i fàcils. Però les dades diuen el contrari.

Segons el Web Almanac 2024 (l'informe anual de referència sobre l'estat del web), una web normal carrega 558 KB de JavaScript. D'aquests, gairebé la meitat (el 44%) no s'utilitza durant la càrrega. Són bytes que viatgen, es descomprimeixen, s'analitzen i s'executen sense que serveixin per a res visible.

I aquí ve la paradoxa: un document HTML amb CSS es renderitza pràcticament a velocitat de xarxa. El navegador el rep i el mostra. El JavaScript, en canvi, costa com a mínim tres vegades més de processar per byte que l'HTML o el CSS, segons les anàlisis d'Alex Russell, enginyer del projecte Chrome a Google. Cada kilobyte de JavaScript que afegim a una pàgina penalitza la velocitat de càrrega tres vegades més que el mateix kilobyte en qualsevol altre format.

El pes dels frameworks

Els frameworks de JavaScript (eines com React, Next.js, Angular o Vue que estructuren la construcció d'una pàgina web) es van crear per resoldre problemes reals: gestionar aplicacions complexes amb molta interacció, com un editor de documents o un panell de control en temps real. El problema és que s'han convertit en l'opció per defecte per a tot, inclosos llocs que són essencialment documents: una web corporativa, un catàleg, un blog.

El resultat és mesurable. El Web Almanac Jamstack 2024 compara el JavaScript que envien els llocs generats amb diferents eines, i les diferències són enormes: un lloc pregenerat amb Next.js (un dels frameworks més populars) envia 3,5 vegades més JavaScript que un lloc equivalent fet amb Astro, un generador pensat per enviar el mínim possible. I tots dos estan classificats com a "estàtics".

Per posar-ho en context: el blog d'Alex Russell carrega en 1,2 segons, amb 120 KB de recursos totals, dels quals només 8 KB són JavaScript. Una web normal en carrega 558 KB només de JavaScript. La diferència no és de tecnologia: és de decisió.

Quantes webs realment necessiten tot això?

El 42% dels llocs web del món funcionen amb WordPress. El 29% no utilitzen cap sistema de gestió de continguts. La immensa majoria de llocs web són, en essència, conjunts de pàgines que canvien poc: un restaurant que actualitza la carta un cop al mes, un despatx d'advocats que no toca la web en un any, una botiga que afegeix productes un cop per setmana.

Malgrat això, el 94,5% dels llocs web es classifiquen com a dinàmics (és a dir, cada visita genera la pàgina des de zero al servidor). Només el 0,5% són purament estàtics i un 5% híbrids. Però entre les 10.000 pàgines amb més trànsit del món, el 12% ja són estàtiques o híbrides, i aquesta xifra ha crescut un 67% en un sol any. Les webs pregenerades pesen, de mitjana, un 43% del que pesen les seves equivalents dinàmiques.

La pregunta és directa: quants d'aquests llocs dinàmics realment necessiten ser-ho?

L'alternativa: HTML generat i SEO programàtic

La idea és senzilla: si ja tens les dades (productes, serveis, propietats, imatges), un programa pot llegir-les i generar totes les pàgines HTML que necessitis. Sense framework al navegador, sense servidor permanent processant peticions, sense manteniment diari. Aquesta estratègia es coneix com a SEO programàtic: en lloc de redactar contingut a mà per cada pàgina, un programa combina una plantilla amb les teves dades i produeix centenars o milers de pàgines, cadascuna orientada a una cerca concreta que la gent fa a Google.

Els beneficis són directes:

• Escala sense esforç manual: un catàleg de 500 productes genera 500 pàgines indexables sense que ningú les escrigui una per una.
• Paraules clau de cua llarga: cada pàgina apunta a cerques molt concretes ("canvi dòlar a euro avui", "pis de 3 habitacions a Gràcia") on hi ha menys competència i més intenció de compra.
• Cost d'adquisició baix: un cop muntat el generador, el cost de crear la pàgina 501 és pràcticament zero.
• Manteniment centralitzat: si canvies la plantilla, totes les pàgines s'actualitzen. Si canvien les dades, les pàgines es regeneren soles.

No és una estratègia nova ni experimental. Algunes de les webs amb més trànsit del món la utilitzen:

• Wise (el servei de transferències internacionals) genera 14.888 pàgines de conversió de divises. Cada parell de monedes (dòlars a euros, rupes a pesos...) té la seva pròpia pàgina amb tipus de canvi reals, comparatives amb bancs i la possibilitat de fer la transferència directament. 4,7 milions de visites orgàniques al mes.
• Zapier (la plataforma d'automatització) genera més de 800.000 pàgines que mostren integracions entre productes. Cada pàgina inclou fluxos de treball concrets i permet activar-los. 306.000 visites orgàniques al mes.
• Nomadlist genera 25.873 pàgines de ciutats per a nòmades digitals, cadascuna amb dades de velocitat d'internet, temperatures, cost de vida i idiomes. 41.200 visites orgàniques al mes.

La clau no és la quantitat de pàgines. La clau és que darrere de cada pàgina hi ha dades reals i rellevants. Sense això, és brossa. El propi Google ho ha advertit: "el SEO programàtic sovint és una etiqueta elegant per a l'spam" (John Mueller, Search Advocate de Google).

No cal ser Wise per aprofitar-ho. Qualsevol negoci amb un catàleg organitzat ja té el que cal.

Un exemple real: 94 pàgines en 3 segons

Per il·lustrar el concepte, vam construir un generador que fa exactament això. Unes 200 línies de TypeScript, executades amb Bun (un entorn que fa funcionar programes JavaScript fora del navegador).

La font de dades: el catàleg públic d'imatges de la NASA, accessible a través d'una API (un servei que permet que qualsevol programa consulti el seu contingut automàticament). Cada entrada del catàleg inclou títol, descripció, data de publicació, paraules clau i una imatge en alta resolució.

El procés:

1. El programa consulta el catàleg amb una paraula clau (en aquest cas, "nebula") i rep 94 resultats
2. Per cada resultat, genera una pàgina HTML amb la imatge, la descripció i els enllaços a pàgines relacionades
3. Crea una galeria amb totes les miniatures
4. Genera un cercador que funciona sense JavaScript (filtrant directament per HTML)
5. Escriu les metadades (títol, descripció, imatge) perquè Google pugui indexar cada pàgina individualment

Tot en menys de 3 segons. I el punt important: canviant la paraula "nebula" per "mars", "saturn" o "galaxy", el mateix generador produeix un lloc completament diferent amb les seves pròpies pàgines, imatges i metadades. Una sola línia de configuració, un catàleg sencer.

I el punt clau: el resultat final és HTML pur amb CSS. No hi ha framework, no hi ha JavaScript al navegador del visitant, no hi ha servidor processant cada petició. El visitant rep fitxers estàtics i prou. Per això és imbatiblement ràpid.

Si en lloc d'imatges de la NASA la font fos el catàleg d'una botiga, les propietats d'una immobiliària o els plats d'un restaurant, el resultat seria el mateix: un lloc web complet, indexable per Google i allotjable en qualsevol servidor bàsic.

Com es manté actualitzat?

Un lloc estàtic no vol dir un lloc abandonat. Hi ha diverses maneres d'automatitzar la regeneració:

• Tasca programada (cronjob): un rellotge que executa el generador cada dia, setmana o hora. Si el catàleg ha canviat, les pàgines es regeneren. Si no ha canviat, el resultat és idèntic i no hi ha cost.
• Webhook (avís automàtic): quan la font de dades canvia, envia un senyal al sistema i les pàgines es regeneren sota demanda. Només es reconstrueix quan cal.
• Pipeline CI/CD (integració contínua): cada cop que es publica una actualització al codi o a les dades, el sistema reconstrueix automàticament tot el lloc.

Cap d'aquestes opcions requereix intervenció manual. I si un dia no hi ha canvis, no hi ha procés.

Per a què serveix i per a què no

Funciona bé per a:

• Catàlegs de productes que ja existeixen en format digital
• Webs de contingut repetitiu: fitxes, llistats, directoris
• Llocs que necessitin presència a Google sense haver de crear contingut a mà per cada pàgina
• Projectes on la velocitat de càrrega és prioritària

No és la solució per a:

• Aplicacions amb interacció en temps real (xats, editors col·laboratius, panells de control)
• Webs amb contingut personalitzat per usuari (rere autenticació)
• Projectes on el contingut canvia cada minut

Reflexió

La indústria web porta un parell de dècades convincent-nos que construir un web és un problema complex que requereix eines complexes. Per a una fracció de llocs, és cert: una aplicació bancària, un editor de vídeo al núvol o un panell de dades en temps real justifiquen cada byte de JavaScript que carreguen. Però per a la gran majoria de llocs (la web corporativa, el catàleg, el portafoli, el blog), el web més ràpid és el que sempre ha estat: un document HTML amb estils.

Això no vol dir renunciar a JavaScript. Vol dir fer-lo servir tal com és, sense afegir-hi capes i capes de programari al damunt. En el món del desenvolupament, en diuen tornar al "vanilla JavaScript": escriure el codi just i necessari, sense intermediaris. Si vols una animació a la galeria o un efecte visual a la capçalera, afegeixes unes línies de codi i el resultat és fluid. El que no té sentit és carregar mig megabyte d'eines per mostrar el que es podria mostrar amb un fitxer HTML.

I la indústria comença a moure's en aquesta direcció. Hi ha llibreries que pesen menys de 15 KB i fan feines que abans requerien eines de mig megabyte, i projectes reals que han abandonat eines pesants per tornar a solucions més lleugeres. Les tecnologies natives del navegador (les que ja venen incloses, sense instal·lar res) han triplicat la seva presència als webs en dos anys. Alex Russell, enginyer de Chrome, ho resumeix sense embuts: "la ressaca de la festa del JavaScript serà dura". El que va començar com a corrent minoritari s'està convertint en sentit comú.

Posar un aparador bonic amb unes línies de JavaScript és raonable. Construir tota la botiga amb una estructura que pesa més que la mercaderia, no.

Les dades citades en aquest article provenen del Web Almanac 2024 (almanac.httparchive.org), l'HTTP Archive (httparchive.org) i les anàlisis d'Alex Russell (infrequently.org). Les xifres de trànsit de Wise, Zapier i Nomadlist són estimacions d'Ahrefs.