PostCSS el 2026: què fa de debò en un web i què ja no cal

PostCSS no és un preprocessador ni un llenguatge: és un programa que llegeix el teu CSS, el converteix en un arbre i deixa que altres programes el transformin. Per si sol no fa res. El que fa depèn dels plugins que li connectis, i això explica la paradoxa del 2026: és a gairebé tots els webs que es construeixen avui i gairebé cap desenvolupador no el veu. Vite l’executa a cada compilació, Next.js el porta de sèrie, Tailwind s’hi integra a través seu. El fas servir encara que no l’hagis instal·lat.

Aquest article va néixer el 2016, quan PostCSS era la novetat que calia explicar. Deu anys després el que cal explicar és el contrari: què en queda, què ja no cal i què fa de debò en un web real. Per a això últim fem servir el nostre.

Què és PostCSS i què no és

Un preprocessador com Sass és un llenguatge: escrius en una sintaxi pròpia i el compilador la tradueix a CSS. PostCSS és una canonada: hi entra CSS, en surt CSS, i entremig cada plugin fa una transformació concreta. Afegir prefixos de navegador, minificar, traduir sintaxi nova a sintaxi vella, comprovar errors, ordenar propietats. Cada tasca és un mòdul independent i s’instal·la només si cal.

Aquesta arquitectura és la raó que hagi sobreviscut a tota la resta. No competeix amb Sass ni amb Tailwind: tots dos poden anar dins de la canonada. I com que el resultat és CSS normal, es pot treure qualsevol plugin sense reescriure ni una línia d’estils, cosa que amb un preprocessador no passa.

El va escriure Andrey Sitnik, l’autor d’Autoprefixer, i corre sobre Node.js. Els compiladors i preprocessadors els tractem en un altre article; aquí ens quedem amb la canonada.

Els tres plugins que importaven el 2016, i què se n’ha fet

La versió original d’aquest text en recomanava tres. Convé veure com ha envellit cadascun, perquè és la millor lliçó sobre per a què serveix PostCSS.

Autoprefixer era imprescindible: escrivies display: flex i ell hi afegia -webkit-box, -ms-flexbox i la resta. Avui és gairebé innecessari. Els navegadors han convergit, els prefixos nous pràcticament han deixat d’existir i la iniciativa Baseline de Google documenta què funciona a tots ells sense més. Queden casos concrets, -webkit-line-clamp o alguns detalls de Safari, i aquests s’escriuen a mà. Autoprefixer continua funcionant i continua sent el plugin més descarregat, però per inèrcia.

cssnext prometia escriure el CSS del futur i que el plugin el traduís al del present. El projecte va tancar el 2019 i el va substituir postcss-preset-env, que fa el mateix amb més criteri. Però la necessitat s’ha reduït igual que la dels prefixos: les variables, color-mix(), :has() i la imbricació nativa ja són a tots els navegadors. La imbricació, que era la gran raó per fer servir Sass, va arribar a Chrome, Safari i Firefox el 2023.

cssnano és el que continua fent exactament el que feia: minificar. Treure espais, comentaris i redundàncies, fusionar regles, escurçar colors. És la part de la canonada que ningú no discuteix, perquè el pes del CSS es paga a cada visita.

Com el fem servir a ondho.com

Aquest web està fet amb SvelteKit i es compila amb Vite. Vite executa PostCSS sol, sense fitxer de configuració, i nosaltres li hem connectat un únic plugin: cssnano amb l’ajust per defecte. Res més.

Sense Autoprefixer, a consciència. En tot el CSS del lloc hi ha onze línies amb prefix -webkit-, escrites a mà on feien falta, i la resta se serveix sense prefixos i així fa anys que va. Si algun dia un navegador torna a necessitar-los, s’afegeix el plugin a la llista i es recompila; aquest és el sentit de la canonada.

I hi ha un motiu concret perquè la minificació importi aquí més que en altres webs. Totes les pàgines d’ondho.com, 1.708 a l’últim build, es generen com a HTML estàtic, i un guió posterior incrusta el CSS de cada pàgina dins del mateix HTML, en lloc d’enllaçar-lo com a fitxer a part. Es fa perquè el navegador pinti sense esperar una segona petició. La conseqüència és que cssnano decideix quant pesa cada pàgina: en una entrada d’aquest blog el bloc <style> incrustat volta els 80 KB ja minificats, i els 131 fitxers de CSS que produeix la compilació sumen 266 KB en total. Sense minificar, cada visita en carregaria força més.

És la mateixa decisió que prenem als projectes de disseny i desenvolupament web que fem per a clients: la canonada més curta que resolgui el problema que hi ha, no la més completa.

PostCSS davant de Sass, el 2026

No són alternatives. Sass és un llenguatge amb variables, funcions i mixins; PostCSS és la canonada per on passa el CSS ja escrit, vingui de Sass o no. La pregunta real és una altra: et cal Sass? Gairebé tot el que justificava fer-lo servir ja és al CSS natiu, i la imbricació va ser l’última peça. Un projecte nou pot escriure CSS pelat, passar-lo per PostCSS amb dos plugins i no trobar res a faltar. Un projecte amb anys de Sass al damunt té motius per no migrar-lo, però no per començar així.

Tailwind és el cas intermedi: va néixer com a plugin de PostCSS i a la versió 4 té motor propi, tot i que manté la integració amb PostCSS per a qui la necessiti. És un senyal de cap a on va tot plegat, cada eina amb el seu compilador i PostCSS com a capa comuna quan en cal una.

Quan et cal i quan no

Si treballes amb Vite, Next.js, Astro o SvelteKit, ja el tens: no cal instal·lar res. El que sí que cal decidir és quins plugins hi van a dins, i la regla que ens ha funcionat és senzilla: un per problema real, cap per si de cas.

• Minificar: sí, sempre. cssnano o el minificador que porti la teva eina.
• Prefixos: només si l’anàlisi de les teves visites diu que hi ha navegadors que els necessiten. Avui és rar.
• Sintaxi futura: només per a una propietat concreta que vulguis fer servir i encara no sigui a Baseline.
• Linting i ordre de propietats: útils en equip, prescindibles en solitari.

I una comprovació que val per a qualsevol canonada: mira el CSS que arriba al navegador, no el que escrius. És l’únic que el visitant paga.