PostCSS en 2026: qué hace de verdad en una web y qué ya no hace falta

PostCSS no es un preprocesador ni un lenguaje: es un programa que lee tu CSS, lo convierte en un árbol y deja que otros programas lo transformen. Por sí solo no hace nada. Lo que hace depende de los plugins que le enchufes, y eso explica la paradoja de 2026: está en casi todas las webs que se construyen hoy y casi ningún desarrollador lo ve. Vite lo ejecuta en cada compilación, Next.js lo trae de serie, Tailwind se integra a través de él. Lo usas aunque no lo hayas instalado.

Este artículo nació en 2016, cuando PostCSS era la novedad que había que explicar. Diez años después lo que hay que explicar es lo contrario: qué queda de aquello, qué ya no hace falta y qué hace de verdad en una web real. Para lo último usamos la nuestra.

Qué es PostCSS y qué no es

Un preprocesador como Sass es un lenguaje: escribes en una sintaxis propia y el compilador la traduce a CSS. PostCSS es una tubería: entra CSS, sale CSS, y entre medias cada plugin hace una transformación concreta. Añadir prefijos de navegador, minificar, traducir sintaxis nueva a sintaxis vieja, comprobar errores, ordenar propiedades. Cada tarea es un módulo independiente y se instala solo si hace falta.

Esa arquitectura es la razón de que haya sobrevivido a todo lo demás. No compite con Sass ni con Tailwind: los dos pueden ir dentro de la tubería. Y como el resultado es CSS normal, se puede quitar cualquier plugin sin reescribir una línea de estilos, cosa que con un preprocesador no pasa.

Lo escribió Andrey Sitnik, el autor de Autoprefixer, y corre sobre Node.js. Compiladores y preprocesadores los tratamos en otro artículo; aquí nos quedamos con la tubería.

Los tres plugins que importaban en 2016, y qué ha sido de ellos

La versión original de este texto recomendaba tres cosas. Conviene ver cómo ha envejecido cada una, porque es la mejor lección sobre para qué sirve PostCSS.

Autoprefixer era imprescindible: escribías display: flex y él añadía -webkit-box, -ms-flexbox y los demás. Hoy es casi innecesario. Los navegadores han convergido, los prefijos nuevos prácticamente han dejado de existir y la iniciativa Baseline de Google documenta qué funciona en todos ellos sin más. Quedan casos concretos, -webkit-line-clamp o algunos detalles de Safari, y esos se escriben a mano. Autoprefixer sigue funcionando y sigue siendo el plugin más descargado, pero por inercia.

cssnext prometía escribir el CSS del futuro y que el plugin lo tradujera al del presente. El proyecto cerró en 2019 y lo sustituyó postcss-preset-env, que hace lo mismo con más criterio. Pero la necesidad se ha reducido igual que la de los prefijos: las variables, color-mix(), :has() y el anidamiento nativo ya están en todos los navegadores. El anidamiento, que era la gran razón para usar Sass, llegó a Chrome, Safari y Firefox en 2023.

cssnano es el que sigue haciendo exactamente lo que hacía: minificar. Quitar espacios, comentarios y redundancias, fusionar reglas, acortar colores. Es la parte de la tubería que nadie discute, porque el peso del CSS se paga en cada visita.

Cómo lo usamos en ondho.com

Esta web está hecha con SvelteKit y se compila con Vite. Vite ejecuta PostCSS solo, sin fichero de configuración, y nosotros le hemos enchufado un único plugin: cssnano con el ajuste por defecto. Nada más.

Sin Autoprefixer, a propósito. En todo el CSS del sitio hay once líneas con prefijo -webkit-, escritas a mano donde hacían falta, y el resto se sirve sin prefijos y así lleva años. Si algún día un navegador vuelve a necesitarlos, se añade el plugin a la lista y se recompila; ese es el sentido de la tubería.

Y hay un motivo concreto para que la minificación importe aquí más que en otras webs. Todas las páginas de ondho.com, 1.708 en el último build, se generan como HTML estático, y un guion posterior incrusta el CSS de cada página dentro del propio HTML, en lugar de enlazarlo como fichero aparte. Se hace para que el navegador pinte sin esperar a una segunda petición. La consecuencia es que cssnano decide cuánto pesa cada página: en una entrada de este blog el bloque <style> incrustado ronda los 80 KB ya minificados, y los 131 ficheros de CSS que produce la compilación suman 266 KB en total. Sin minificar, cada visita cargaría bastante más.

Es la misma decisión que tomamos en los proyectos de diseño y desarrollo web que hacemos para clientes: la tubería más corta que resuelva el problema que hay, no la más completa.

PostCSS frente a Sass, en 2026

No son alternativas. Sass es un lenguaje con variables, funciones y mixins; PostCSS es la tubería por la que pasa el CSS ya escrito, venga de Sass o no. La pregunta real es otra: ¿te hace falta Sass? Casi todo lo que justificaba usarlo ya está en el CSS nativo, y el anidamiento fue la última pieza. Un proyecto nuevo puede escribir CSS a secas, pasarlo por PostCSS con dos plugins y no echar nada en falta. Un proyecto con años de Sass encima tiene motivos para no migrarlo, pero no para empezar así.

Tailwind es el caso intermedio: nació como plugin de PostCSS y en su versión 4 tiene motor propio, aunque mantiene la integración con PostCSS para quien la necesite. Es una señal de hacia dónde va la cosa, cada herramienta con su compilador y PostCSS como capa común cuando hace falta una.

Cuándo te hace falta y cuándo no

Si trabajas con Vite, Next.js, Astro o SvelteKit, ya lo tienes: no hay que instalar nada. Lo que sí hay que decidir es qué plugins van dentro, y la regla que nos ha funcionado es sencilla: uno por problema real, ninguno por si acaso.

• Minificar: sí, siempre. cssnano o el minificador que traiga tu herramienta.
• Prefijos: solo si el análisis de tus visitas dice que hay navegadores que los necesitan. Hoy es raro.
• Sintaxis futura: solo para una propiedad concreta que quieras usar y aún no esté en Baseline.
• Linting y orden de propiedades: útiles en equipo, prescindibles en solitario.

Y una comprobación que vale para cualquier tubería: mira el CSS que llega al navegador, no el que escribes. Es lo único que el visitante paga.