Minificación

TL;DR — La minificación consiste en eliminar lo que tu código no necesita para funcionar — espacios, saltos de línea y comentarios — de tu CSS, JavaScript y HTML. El archivo sigue funcionando exactamente igual; solo que es más pequeño, por lo que se descarga un poco más rápido. Si PageSpeed Insights alguna vez te dijo “Minify CSS” o “Minify JavaScript,” esta es la solución. No es lo mismo que la compresión.

Qué es la minificación

Los desarrolladores escriben código para que sea legible — con sangrías, espaciado y comentarios que explican qué hace cada parte. A los navegadores no les importa nada de eso. Todo el espacio en blanco y los comentarios que hacen que un archivo sea agradable de leer para un humano son peso muerto puro para un navegador.

La minificación es el proceso automatizado de eliminar ese peso muerto. Un minificador toma tu archivo fuente y elimina:

• espacios, tabulaciones y saltos de línea
• comentarios
• para CSS y JavaScript, puede ir más allá — acortando nombres de variables largos y colapsando sintaxis redundante

Lo que sale es un archivo que hace exactamente lo mismo, solo que más pequeño. Menos bytes para descargar significa que la página carga un poco más rápido.

Dónde te lo encontrarás

Casi todo el mundo conoce la minificación de la misma manera: ejecutan su sitio a través de Google PageSpeed Insights o Lighthouse y ven una advertencia que dice “Minify CSS” o “Minify JavaScript,” con una nota de que podrían ahorrar algunos kilobytes. Esa advertencia es lo que lleva a la mayoría de la gente a buscar qué significa esto.

Lo que la gente suele entender mal

La minificación no es compresión. Suenan similares y a menudo se agrupan, pero son dos trabajos diferentes:

• La minificación reduce el código fuente eliminando caracteres que no necesita.
• La compresión (Gzip o Brotli) reduce el archivo de nuevo mientras viaja por la red, y luego el navegador lo descomprime.

Haces ambas, y en ese orden — primero minifica, luego comprime. Se acumulan. Para la parte de compresión de la historia, consulta la guía hermana de compresión.

¿Necesitas siquiera hacerlo tú mismo?

Probablemente no, si estás en una configuración moderna. Herramientas como los plugins de rendimiento de WordPress, o frameworks como Next.js, manejan la minificación automáticamente por ti. La advertencia de auditoría tiende a aparecer principalmente en sitios antiguos, código escrito a mano, o scripts añadidos por plugins de terceros. Y sinceramente — la minificación vale la pena hacerla, pero es una victoria pequeña. Los problemas de velocidad más grandes suelen venir de imágenes o scripts que bloquean el renderizado, no de CSS sin minificar.

¿Quieres la versión real — cómo funciona por tipo de archivo, la mecánica de la auditoría de PageSpeed, lo que los bundlers modernos hacen por ti, las herramientas que Google nombra explícitamente, y si afecta al SEO en absoluto? Cambia a la pestaña Avanzado.

TL;DR — La minificación elimina caracteres que un archivo no necesita para funcionar — espacios en blanco, saltos de línea, comentarios y (para CSS/JS) identificadores largos y sintaxis redundante — del código fuente CSS, JS y HTML, sin cambiar cómo el navegador lo analiza o ejecuta. La documentación de Lighthouse de Google lo define y audita como unminified-css / unminified-javascript. Aclara primero la confusión #1: la minificación ≠ compresión (Gzip/Brotli, una codificación a nivel de transporte aplicada encima — minifica primero, luego comprime) y ≠ concatenación/agrupación (combinar archivos para reducir solicitudes HTTP) o tree-shaking/eliminación de código muerto (probar que el código es inalcanzable). Los minificadores de CSS/JS pueden ser agresivos; la minificación de HTML es más superficial y arriesgada. No hay un porcentaje de ahorro universal — mide tus propios archivos — y un archivo más pequeño por sí solo no prueba menos ejecución o una mejora de Core Web Vitals/Search; es una optimización de apoyo, no una bala de plata, y no es un factor de clasificación directo. Los bundlers modernos (Webpack, Vite, Next.js, esbuild) minifican la salida de producción por defecto, por lo que la auditoría principalmente se activa para sitios heredados, código en línea o activos de terceros/plugins. Herramientas nombradas: HTMLMinifier, CSSNano/csso, UglifyJS/Terser/Closure Compiler.

Qué es realmente la minificación

La minificación es la eliminación de caracteres que un archivo no necesita para ser analizado o ejecutado. La documentación de Lighthouse de Google lo expresa claramente en la auditoría de JavaScript: “Minification is the process of removing whitespace and any code that is not necessary to create a smaller but perfectly valid code file.” (traducción) «La minificación es el proceso de eliminar espacios en blanco y cualquier código que no sea necesario para crear un archivo de código más pequeño pero perfectamente válido». El documento más antiguo de PageSpeed Insights de Google enmarca el caso general de la misma manera: la minificación “refers to the process of removing unnecessary or redundant data without affecting how the resource is processed by the browser.” (traducción) «se refiere al proceso de eliminar datos innecesarios o redundantes sin afectar cómo el navegador procesa el recurso».

La frase clave en ambas es sin afectar cómo el navegador lo procesa. Esa es la intención: se supone que la salida preserve el comportamiento de la entrada, no solo que se le parezca. Estás eliminando las partes que solo existieron para la legibilidad humana — la indentación, las líneas en blanco, los comentarios — además, para CSS y JS, acortando identificadores y colapsando sintaxis redundante que el analizador no necesita que se le especifique. Pero “destinado a preservar el comportamiento” y “realmente preserva el comportamiento en tu código base” no son automáticamente lo mismo — un minificador correcto tiene que analizar el lenguaje en lugar de eliminar caracteres mecánicamente (ver los casos límite a continuación), por lo que el flujo de trabajo que importa es probar el artefacto minificado y de producción — no solo asumir que la eliminación de bytes es segura para el comportamiento por definición.

La recompensa son los bytes. Menos bytes para descargar, y para CSS/JS específicamente, menos texto para que el navegador tokenice antes de poder construir el CSSOM o ejecutar el script. Esa última parte es por lo que la minificación pertenece a la conversación sobre la ruta de renderizado crítica — el trabajo de la ruta crítica para llegar al primer pintado es, en parte, sobre minimizar los bytes críticos en la ruta, y la minificación es una de las palancas que lo logra.

Minificación vs. compresión vs. concatenación

Esta es la desambiguación que hay que hacer bien antes que cualquier otra cosa, porque la industria confunde los tres constantemente.

La minificación elimina caracteres redundantes dentro de un archivo fuente. Opera sobre el código en sí, en tiempo de compilación (o mediante un plugin/CDN), y el resultado sigue siendo texto cercano a lo humano — solo que feo.

La compresión (Gzip, Brotli) es una codificación a nivel de transporte aplicada a la respuesta sobre un archivo ya minificado. La guía de minificación para SEO de OnCrawl traza la línea bien: la compresión “involves rewriting a file’s binary code and encoding it using fewer bits,” (traducción) «implica reescribir el código binario de un archivo y codificarlo usando menos bits», que es un mecanismo fundamentalmente diferente de la eliminación de caracteres de la minificación. Los dos son complementarios y normalmente se aplican ambos, en orden: minifica, luego comprime. (La historia completa de Gzip/Brotli/Zstd está en la inmersión profunda de compresión.)

La concatenación / agrupación combina múltiples archivos en uno para reducir el número de solicitudes HTTP. OnCrawl de nuevo: la concatenación “joins two or more code functions… into a single command,” (traducción) «une dos o más funciones de código… en un solo comando», lo que resuelve un problema de número de solicitudes, no un problema de bytes por archivo. Los bundlers modernos hacen la minificación y la concatenación juntas en un solo paso, que es una gran razón por la que los dos se confunden — pero abordan diferentes cuellos de botella.

Hay dos operaciones más que vale la pena separar, porque una sola herramienta de compilación suele realizar todas ellas y la terminología se usa de forma imprecisa: tree-shaking demuestra que un fragmento de código es inalcanzable desde cualquier punto de entrada y lo excluye del bundle; eliminación de código muerto es la pasada relacionada que elimina el código que una compilación determina que nunca puede ejecutarse (una rama if (false), por ejemplo). Ninguna de las dos es minificación: la minificación acorta la sintaxis del código que sí se va a enviar; el tree-shaking y la eliminación de código muerto deciden qué se envía en absoluto. Terser, por ejemplo, expone estos como controles genuinamente separados: compress (reescritura de sintaxis), mangle (acortamiento de identificadores) y unused (eliminación de código que la herramienta puede demostrar que no está referenciado) son opciones distintas, no un único ajuste, porque cada una puede ser segura o insegura independientemente de las demás según tu base de código.

Una forma útil de entenderlo: minificar = menos bytes por archivo; empaquetar/concatenar = menos solicitudes; tree-shake/eliminar código muerto = menos código enviado en absoluto; comprimir = menos bytes en la red. Estos son eslabones complementarios en la misma canalización, y el orden/composición exactos dependen de tu herramienta de compilación: shake/eliminar código muerto → minificar → (opcionalmente) empaquetar → comprimir → cachear.

Cómo funciona, por tipo de archivo

Los tres tipos de archivo no se minifican de la misma manera, y la mayor parte del contenido de la competencia los trata como si lo fueran.

CSS. Los minificadores eliminan espacios en blanco, comentarios y el punto y coma final en un bloque; colapsan la forma larga en la forma abreviada cuando es seguro (margin: 0px 0px 0px 0px → margin:0), fusionan selectores duplicados y acortan los valores de color (#ffffff → #fff). La minificación de CSS puede ser bastante agresiva porque la estructura de una hoja de estilos es fácil de analizar de forma segura, con una excepción específica: las propiedades personalizadas de CSS (--my-var:). Según la especificación de CSS, los nombres de las propiedades personalizadas distinguen entre mayúsculas y minúsculas, y el flujo de tokens del valor, incluidos los espacios en blanco dentro de él, puede conservarse y volverse significativo una vez que la propiedad se sustituye con var(). Un minificador que trata un valor de propiedad personalizada como espacios en blanco ordinarios de CSS puede cambiar a lo que realmente resuelve la sustitución.

JavaScript. Aquí es donde la minificación llega más lejos. Más allá de la eliminación de espacios en blanco y comentarios, un minificador de JS renombra variables locales y parámetros de funciones a letras individuales (getUserProfile → a), elimina código muerto inalcanzable y colapsa expresiones. Dos mecanismos hacen que este sea el más arriesgado de los tres: primero, las reglas de Inserción Automática de Punto y Coma de JavaScript son sensibles a los terminadores de línea, por lo que un minificador correcto tiene que analizar el lenguaje y emitir sintaxis válida en lugar de eliminar mecánicamente espacios en blanco; si te equivocas, puedes cambiar silenciosamente lo que hace el código. Segundo, el mangling de identificadores/propiedades (acortamiento de nombres) puede romper código que depende de la visibilidad del ámbito de eval/with, de Function.name o del nombre de una clase, del acceso dinámico/entre comillas a propiedades, o de un contrato con código fuera del bundle (un built-in del DOM, una integración de terceros), por lo que minificadores como Terser exponen controles explícitos eval, keep_fnames y keep_classnames/mangling de propiedades en lugar de hacer mangling de todo por defecto. Más sobre cómo probar esto en Riesgos más abajo.

HTML. La minificación de HTML es deliberadamente la más conservadora de las tres — normalmente solo elimina comentarios y colapsa espacios en blanco redundantes. Una reescritura de HTML más agresiva corre el riesgo de alterar el marcado renderizado o el comportamiento, por lo que los minificadores dejan la mayor parte de la estructura intacta. Ese conservadurismo está justificado: según el estándar HTML, los espacios en blanco no se pueden descartar de manera uniforme: el analizador crea o descarta nodos de texto de forma diferente según dónde se encuentre el espacio en blanco y en qué elemento esté, y los elementos de “texto sin procesar”/“texto sin procesar escapable” (como <script>, <style>, <textarea>) tienen sus propias reglas de análisis donde el contenido no se trata como marcado ordinario en absoluto. Este es el matiz que la mayoría de los análisis omiten: minificar HTML es más superficial y de menor rendimiento que minificar CSS/JS, precisamente porque HTML tiene menos peso muerto que se pueda eliminar de forma segura y un mayor radio de impacto si te equivocas: un minificador de HTML necesita razonar sobre la salida renderizada, no solo eliminar caracteres que parecen redundantes.

¿Cuánto ahorra realmente?

No hay un número universal aquí, y cualquier porcentaje único que veas citado para ahorros “típicos” de minificación describe los archivos de otra persona con su propio formato y herramientas, no los tuyos. La diferencia depende de lo verboso que fuera tu código fuente desde el principio (el código fuente con muchos comentarios y sangría se reduce más que el código ya conciso), qué minificador y opciones ejecutes, si un paso de compilación anterior ya eliminó parte de él y, aparte de todo eso, si el archivo se sirve comprimido, ya que Gzip/Brotli ya colapsan muchos espacios en blanco repetitivos por sí solos, que es exactamente el tipo de bytes que la minificación también elimina. La única forma fiable de conocer tu propio número es medir tus propios archivos: ejecuta las auditorías Minify CSS/JavaScript de PageSpeed Insights/Lighthouse contra tu URL de producción real, o compara los tamaños de archivo antes y después de ejecutar tu propio minificador.

Ten el mismo cuidado con lo que demuestra una reducción de bytes. Un archivo más pequeño puede reducir el tiempo de transferencia y, para CSS/JS, el tiempo que el navegador dedica a la tokenización antes de poder construir el CSSOM o ejecutar el script: ese es el beneficio real y acotado. No prueba por sí solo menos ejecución de JavaScript, menos trabajo en el hilo principal, menos selectores CSS que coincidir, ni que se haya eliminado código muerto: la minificación cambia cómo se escribe el código, no lo que hace en tiempo de ejecución; eso es un trabajo aparte (consulta tree-shaking/eliminación de código muerto arriba). Y menos bytes de origen no se traducen automáticamente en una mejora medible de Core Web Vitals o de búsqueda: si importa depende de si el tamaño de transferencia o el tiempo de análisis es realmente tu cuello de botella. Minificar una hoja de estilo que ya era pequeña, en una página cuyo cuello de botella real es una imagen hero gigante o un montón de scripts de terceros que bloquean el renderizado, no moverá tu LCP de una manera que puedas notar. La minificación es una optimización de apoyo: real, que vale la pena hacer y barata de automatizar, pero rara vez la solución única para una página lenta. Mide tu cuello de botella real antes de dedicar mucho tiempo a perseguir KiB aquí.

La auditoría de PageSpeed Insights / Lighthouse

La razón por la que la mayoría de la gente está aquí. Lighthouse ejecuta dos auditorías relevantes: Minify CSS (unminified-css) y Minify JavaScript (unminified-javascript) — y las reporta en Opportunities. Los documentos de Google describen el mecanismo de la misma manera para ambas: “The Opportunities section of your Lighthouse report lists all unminified CSS files, along with the potential savings in kibibytes (KiB) when these files are minified.” (traducción) «La sección de Oportunidades de tu informe de Lighthouse enumera todos los archivos CSS no minificados, junto con los ahorros potenciales en kibibytes (KiB) cuando estos archivos se minifican.» Para JavaScript, Google señala el beneficio doble: “Minifying JavaScript files can reduce payload sizes and script parse time.” (traducción) «Minificar archivos JavaScript puede reducir los tamaños de carga útil y el tiempo de análisis de scripts.»

Dos cosas a tener en cuenta al leer ese informe:

• La cifra de KiB es una estimación del ahorro potencial, no una garantía de mejora en la velocidad de la página. Te indica cuánto más pequeño podría ser el archivo, no cuánto más rápido se sentirá la página.
• La auditoría se ejecuta por archivo, y cada vez más los infractores son archivos que no controlas directamente — widgets de terceros, scripts de anuncios, recursos de plugins de CMS — en lugar de tu propio código empaquetado (consulta la siguiente sección).

¿Realmente necesitas hacer esto manualmente?

Para la mayoría de las pilas modernas, no. Las compilaciones de producción de Webpack (v4+ incluye un plugin de Terser por defecto), Vite, Next.js y esbuild minifican la salida automáticamente. El propio documento de JS de Google menciona las herramientas directamente — “Terser is a popular JavaScript compression tool,” (traducción) «Terser es una herramienta popular para comprimir JavaScript», y “webpack v4 includes a plugin for this library by default to create minified build files.” (traducción) «webpack v4 incluye un complemento para esta biblioteca de forma predeterminada con el que crea archivos de compilación minificados». Si envías una compilación de producción desde cualquiera de estas, tu propio código ya está minificado; estás “en cumplimiento” sin hacer nada.

Entonces, ¿cuándo sigue apareciendo la auditoría? Principalmente por:

• Sitios heredados / sin empaquetar que sirven etiquetas <style> y <script> escritas a mano sin paso de compilación.
• Scripts de terceros — análisis, widgets de chat, etiquetas de anuncios — que cargas pero no compilas, y no puedes minificar tú mismo.
• Temas y plugins de CMS que envían recursos sin minificar.
• Bloques <style>/<script> en línea que un empaquetador nunca tocó.

Este es el ángulo de coste que los competidores pasan por alto: para un sitio moderno bien construido, la advertencia “Minify JavaScript” a menudo se refiere a recursos fuera de tu canal de compilación, no a una señal de que olvidaste minificar tu propio código.

Cómo minificar (y las herramientas que Google menciona)

Para código hecho a mano o heredado, la documentación de PageSpeed Insights de Google menciona herramientas específicas por tipo de archivo:

• HTML — HTMLMinifier.
• CSS — CSSNano y csso.
• JavaScript — UglifyJS y el propio Closure Compiler de Google. (El documento de JS más reciente de Lighthouse añade Terser como el predeterminado popular.)

El documento de CSS de Google también señala que para cualquier cosa más allá de un proyecto pequeño, la minificación “is usually accomplished with a build tool like Gulp or Webpack” (traducción) «normalmente se consigue con una herramienta de compilación como Gulp o Webpack», en lugar de copiar y pegar manualmente en un minificador en línea. Y hay una opción del lado del servidor: el PageSpeed Module para Apache/Nginx puede minificar respuestas automáticamente sin un paso de compilación separado, y muchos CDN ofercen un interruptor equivalente de minificación automática.

Implementación específica por plataforma

• WordPress. Aquí es donde más a menudo dirijo a la gente, porque la mayoría de los propietarios de WordPress no ejecutan un paso de compilación. Un plugin de rendimiento lo maneja: la configuración de Optimización de Archivos de WP Rocket incluye interruptores “Minify CSS files” y “Minify JavaScript files”, y Autoptimize es una alternativa gratuita sólida si no usas WP Rocket. Recomiendo ambos en mi guía de SEO para WordPress.
• Drupal — habilita “Aggregate JavaScript files” en la configuración de rendimiento del administrador.
• Joomla — los plugins manejan la concatenación/minificación.
• Magento — la guía de Google es usar Terser y deshabilitar el minificador integrado donde entre en conflicto.
• React / Next.js — la compilación de producción minifica automáticamente; generalmente no configuras nada.

Riesgos y pruebas

La minificación es generalmente segura, pero “generalmente” no es “siempre” — y la excepción importa. La minificación agresiva de JavaScript puede ocasionalmente manejar mal la sintaxis de casos límite y romper la funcionalidad: un cambio de nombre de variable que colisiona, una eliminación de código muerto que en realidad no estaba muerto, un plugin que asumía una salida específica sin minificar. En mi escritura de SEO para WordPress señalo exactamente esto: habilitar la minificación puede romper características del sitio en algunos casos, así que prueba en un entorno de staging antes de publicarlo en producción. Esa advertencia se aplica más allá de WordPress: activa la minificación, haz clic en las características interactivas del sitio y confirma que nada se rompió antes de enviarlo.

Más allá de las pruebas funcionales, hay un puñado de efectos secundarios operativos que los equipos pasan por alto porque la minificación parece un cambio puramente cosmético:

• Mapas de origen. La minificación reescribe números de línea, columnas e identificadores, por lo que las herramientas de seguimiento de errores y depuración necesitan un mapa de origen correspondiente (Terser, por ejemplo, admite mapas de entrada encadenados y mapas de salida generados) o tus seguimientos de pila en producción se vuelven ilegibles. Mantén la generación del mapa y la compilación minificada en sincronía, y conserva una forma estable de mapear los errores minificados de una versión de vuelta al código fuente que los produjo.
• Comentarios de licencia/legales. La eliminación de comentarios puede quitar los encabezados de licencia que estás obligado contractualmente a conservar. Los minificadores suelen ofrecer una opción de comentarios conservados o preámbulo de licencia (el manejo de format.comments/preámbulo de Terser, por ejemplo); verifica el valor predeterminado y la versión exactos de tu herramienta antes de asumir que los comentarios de licencia sobreviven.
• Hashes CSP e integridad de subrecursos. Si tu sitio usa un hash de origen de Política de Seguridad de Contenido (CSP) o SRI en una etiqueta de script o estilo, ese hash o resumen se calcula sobre los bytes exactos servidos. Cambiar la salida minificada cambia los bytes, lo que cambia el hash; regenera e implementa el hash CSP o el resumen SRI atómicamente con el nuevo recurso, o el recurso fallará silenciosamente al cargarse bajo una política estricta.
• Paridad del artefacto de producción. Prueba el artefacto que realmente se sirve en producción, no solo tu compilación local, ya que el modo de renderizado del framework, las transformaciones a nivel de CDN, los plugins, la inyección de terceros y el estado de caché pueden producir un recurso diferente al de tu máquina.
• Reversión. La equivalencia de bytes no es prueba de equivalencia de comportamiento. Antes de implementar un cambio de minificación, ten una forma rápida de comparar el comportamiento funcional, visual, de consola, de red y de monitoreo con la compilación sin minificar, y una ruta rápida de reversión si algo regresa después del despliegue.

¿La minificación afecta al SEO?

No directamente. Ninguna documentación oficial de Google nombra la minificación como una señal de clasificación. Es una entrada al tamaño del archivo, que es una entrada a la velocidad de página y a las Core Web Vitals, que son, como mucho, una consideración de clasificación menor, de desempate. Preguntado si minificar HTML y CSS ayuda al SEO, John Mueller de Google ha dicho (según la cobertura de Search Engine Roundtable) que reducir esos archivos puede valer la pena investigar, dejando claro que el impacto depende de cuán infladas estén tus páginas para empezar; una práctica de velocidad y UX, no una palanca de clasificación. Ese es el marco correcto: vale la pena hacerlo por higiene de rendimiento, no porque Google recompense el HTML minificado.

Este es también mi propio consejo de larga data en el lado del rendimiento. En mi guía de LCP, dentro de una sección sobre hacer los archivos más pequeños para mejorar la Largest Contentful Paint, lo dije sin rodeos: “You should minify any CSS you have.” (traducción) «Deberías minificar cualquier CSS que tengas». Y lo combino con eliminar CSS no utilizado y minificar tu JavaScript; la minificación es un movimiento en la parte de reducción de tamaño de archivo de una corrección de LCP, junto con la compresión y la eliminación de código muerto.

Dónde encaja en la pila de rendimiento

Piensa en la minificación como un eslabón en una cadena, no toda la cadena:

minificar → (opcionalmente) agrupar/concatenar → comprimir (Gzip/Brotli) → almacenar en caché (Cache-Control/CDN).

Cada eslabón hace un trabajo diferente, y las mayores ganancias de velocidad suelen venir de otra parte del camino: eliminar recursos que bloquean el renderizado, optimizar imágenes, reducir el tiempo de respuesta del servidor. La minificación gana su lugar porque es barata, automatizable y se apila limpiamente con todo lo demás. Solo no te la vendas de más.

Temas relacionados: a dónde ir después

Esta página se encuentra bajo el centro de ruta de renderizado crítica, junto con su hermano más cercano, compresión — léelos juntos, ya que la minificación y la compresión son las dos mitades de “hacer el texto más pequeño” y se confunden constantemente. Desde allí, el grupo más amplio de rendimiento web cubre las métricas en las que se basa la minificación: Core Web Vitals, Largest Contentful Paint, First Contentful Paint — y el trabajo de recursos que bloquean el renderizado, que suele importar más que la minificación por sí sola.

Resumen de IA

Una versión condensada de la versión avanzada:

• Minificación = eliminar caracteres que un archivo no necesita para funcionar — espacios en blanco, saltos de línea, comentarios y (para CSS/JS) identificadores largos y sintaxis redundante — del código fuente CSS, JS y HTML, “without affecting how the resource is processed by the browser.” (traducción) «sin afectar cómo el navegador procesa el recurso». Google lo audita como unminified-css / unminified-javascript.
• No es compresión, ni concatenación, ni tree-shaking/eliminación de código muerto. La compresión (Gzip/Brotli) es una codificación a nivel de transporte aplicada sobre archivos minificados (minifica primero, luego comprime). La concatenación/agrupación combina archivos para reducir las solicitudes HTTP. El tree-shaking/eliminación de código muerto decide qué código se envía; la minificación acorta la sintaxis de lo que se envía. Cuatro palancas complementarias, no sinónimos.
• Por tipo de archivo, con casos límite: CSS y JS se pueden minificar agresivamente (renombrar variables, eliminar código muerto), pero los flujos de tokens de propiedades personalizadas de CSS y la Inserción Automática de Punto y Coma de JS / la mutilación de propiedades de identificador necesitan un minificador que realmente analice el lenguaje, no uno que elimine caracteres mecánicamente. La minificación de HTML es más superficial y arriesgada (principalmente comentarios + espacios en blanco) porque el manejo de espacios en blanco y los elementos de texto sin procesar son sensibles al analizador y reescribir el marcado puede romper cosas.
• No hay un porcentaje de ahorro universal — depende de tus propios archivos fuente; mide. Un archivo más pequeño no prueba por sí solo menos ejecución o una mejora de Core Web Vitals/Search — eso depende de si el tiempo de transferencia/análisis era realmente tu cuello de botella; una optimización de apoyo, no una bala de plata.
• Seguridad en el despliegue: cambiar los bytes minificados cambia los mapas de origen, puede eliminar comentarios de licencia e invalida los hashes CSP/digestos SRI — regenera y vuelve a desplegar esos atómicamente, prueba el artefacto de producción real y mantén una ruta de reversión.
• No es un factor de clasificación directo. Ningún documento de Google lo nombra como tal; Mueller ha enmarcado la minificación de HTML/CSS como algo que vale la pena hacer por velocidad/UX, dependiendo de cuán infladas estén las páginas — una entrada de experiencia de página, no una palanca de clasificación.
• Los bundlers modernos minifican por defecto (Webpack v4+/Terser, Vite, Next.js, esbuild), por lo que la auditoría se activa principalmente en sitios heredados, código en línea o activos de terceros/plugins.
• Herramientas nombradas: HTMLMinifier (HTML); CSSNano/csso (CSS); UglifyJS/Terser/Closure Compiler (JS). WordPress: WP Rocket / Autoptimize.
• Riesgo: la minificación agresiva de JS puede romper la funcionalidad — prueba en staging primero.

Documentación oficial

Documentación de fuentes primarias sobre minificación.

Google

• Minificar CSS (unminified-css) — la auditoría de Lighthouse: por qué los archivos CSS suelen ser más grandes de lo necesario, cómo Opportunities informa sobre los posibles ahorros en KiB y orientación específica para cada plataforma. (El web.dev/articles/minify-css de Google redirige con 301 a esta URL canónica).
• Minificar JavaScript (unminified-javascript) — la auditoría de JS: la definición de minificación, los beneficios de carga y tiempo de análisis, Terser y el complemento predeterminado de webpack.
• Minificar recursos (HTML, CSS y JavaScript) — el documento heredado de PageSpeed Insights, la mejor fuente oficial que menciona la minificación de HTML junto con CSS/JS, y nombra herramientas (HTMLMinifier, CSSNano/csso, UglifyJS/Closure Compiler).
• Reducir el tamaño del frontend — la minificación dentro de un flujo de trabajo más amplio de reducción de tamaño centrado en Webpack (empaquetado, tree-shaking y minificación juntos).
• Optimizar la codificación y el tamaño de transferencia de los recursos de texto — enmarca la eliminación de comentarios como complementaria a la compresión a nivel de código.

Bing / Microsoft

• No se encontró documentación específica de Bing/Microsoft sobre la minificación de CSS/JS/HTML. Bing Webmaster Tools ofrece orientación general sobre la velocidad del sitio y diagnósticos, pero nada que mencione la minificación como lo hacen los documentos de Lighthouse de Google, lo que es coherente con que Bing rara vez publique orientación detallada sobre la implementación del rendimiento front-end.

Citas de la fuente

Declaraciones oficiales de la documentación de Google, además de una voz de la industria. Cada enlace es un enlace profundo que salta al pasaje citado en la página de origen.

Google — qué es la minificación

• “Minification is the process of removing whitespace and any code that is not necessary to create a smaller but perfectly valid code file.” (traducción) «El proceso de minificación elimina los espacios en blanco y el código innecesario para producir un archivo válido más pequeño». (traducción) «La minificación es el proceso de eliminar espacios en blanco y cualquier código que no sea necesario para crear un archivo de código más pequeño pero perfectamente válido». — Documentos de Google Lighthouse (Minify JavaScript). Ir a la cita
• “Minification refers to the process of removing unnecessary or redundant data without affecting how the resource is processed by the browser.” (traducción) «Minificar consiste en quitar datos superfluos o redundantes sin cambiar la forma en que el navegador procesa el recurso». (traducción) «La minificación se refiere al proceso de eliminar datos innecesarios o redundantes sin afectar cómo el navegador procesa el recurso». — Documentos de Google PageSpeed Insights (Minify Resources). Ir a la cita

Google — por qué importa y cómo se mide

• “Minifying JavaScript files can reduce payload sizes and script parse time.” (traducción) «La minificación de archivos JavaScript puede reducir la carga y el tiempo de análisis de los scripts». (traducción) «Minificar archivos JavaScript puede reducir los tamaños de carga y el tiempo de análisis de scripts». Ir a la cita
• “The Opportunities section of your Lighthouse report lists all unminified CSS files, along with the potential savings in kibibytes (KiB) when these files are minified.” (traducción) «La sección de Oportunidades de tu informe de Lighthouse enumera todos los archivos CSS no minificados, junto con los posibles ahorros en kibibytes (KiB) cuando esos archivos se minifican». (traducción) «La sección de Oportunidades de tu informe de Lighthouse enumera todos los archivos CSS no minificados, junto con los posibles ahorros en kibibytes (KiB) cuando estos archivos se minifican». — Documentos de Google Lighthouse (Minify CSS). Ir a la cita
• “Minifying CSS files can improve your page load performance. CSS files are often larger than they need to be.” (traducción) «Minificar archivos CSS puede acelerar la carga de la página; a menudo ocupan más de lo necesario». (traducción) «Minificar archivos CSS puede mejorar el rendimiento de carga de tu página. Los archivos CSS suelen ser más grandes de lo necesario». Ir a la cita

Google — herramientas

• “Terser is a popular JavaScript compression tool.” (traducción) «Terser es una herramienta conocida para comprimir JavaScript». Y: “webpack v4 includes a plugin for this library by default to create minified build files.” (traducción) «webpack v4 trae de forma predeterminada un complemento de esta biblioteca para crear compilaciones minificadas». Ir a la cita

Industria — OnCrawl (empresa), sobre la desambiguación

• Sobre la compresión: “involves rewriting a file’s binary code and encoding it using fewer bits,” (traducción) «implica reescribir el código binario del archivo y codificarlo con menos bits», un mecanismo diferente de la eliminación de caracteres de la minificación. Sobre la concatenación: “joins two or more code functions… into a single command,” (traducción) «une varias funciones de código… en un único comando», lo que aborda el número de solicitudes, no el tamaño del archivo. Leer la guía

Patrick Stox (yo) — la minificación como palanca de LCP

• “You should minify any CSS you have.” (traducción) «Conviene minificar todo el CSS que tengas». — de mi guía de LCP de Ahrefs, en una sección sobre cómo hacer los archivos más pequeños. Leer la guía

Auditoría de minificación — lista de verificación

Una pasada para confirmar que tus activos de texto están minificados sin romper nada:

• Ejecuta la URL a través de PageSpeed Insights / Lighthouse y revisa las auditorías “Minify CSS” y “Minify JavaScript” en Oportunidades.
• Confirma que tu compilación de producción minifica (Webpack/Terser, Vite, Next.js, esbuild) — si envías una compilación de desarrollo a producción, ese es el error real.
• Identifica qué archivos marcados son tuyos vs. de terceros (widgets, anuncios, análisis) o activos de plugins de CMS que no compilas.
• En WordPress sin paso de compilación, habilita la minificación mediante WP Rocket (Optimización de archivos) o Autoptimize — y prueba primero en staging.
• Revisa los bloques en línea <style> / <script> que un bundler podría haber omitido.
• Confirma que la minificación se aplica antes de la compresión — minifica, luego Gzip/Brotli.
• Después de habilitarla, haz clic en las funciones interactivas (formularios, menús, deslizadores, checkout) para confirmar que la minificación agresiva de JS no rompió nada.
• No te obsesiones con el número de KiB — compáralo con palancas más grandes (imágenes, recursos que bloquean el renderizado, tiempo de respuesta del servidor) antes de dedicar mucho tiempo aquí.
• Vuelve a ejecutar PageSpeed para confirmar que la auditoría se resuelve (o que los infractores restantes son activos de terceros fuera de tu control).

Los modelos mentales

1. Tres palancas, tres trabajos diferentes. Minificar = menos bytes por archivo. Agrupar/concatenar = menos solicitudes. Comprimir = menos bytes en la red. Se apilan en ese orden (minificar → agrupar → comprimir → cachear), y confundir una con otra desperdicia esfuerzo. Cuando alguien dice “comprime tu CSS”, pregunta qué palanca quiere decir realmente.

2. Funcionalmente idéntico, solo más pequeño. Toda la promesa de la minificación es que el comportamiento de salida es igual al comportamiento de entrada — “without affecting how the resource is processed by the browser.” (traducción) «sin afectar cómo el navegador procesa el recurso». Si un cambio altera el comportamiento, eso no es minificación funcionando, es minificación rompiendo. Este es el marco que te dice cuándo ser sospechoso (JS agresivo) vs. relajado (espacios en blanco HTML).

3. La agresión escala con la seguridad. El CSS/JS se puede minificar de forma agresiva porque las herramientas de compilación pueden analizar su estructura de manera segura; el HTML se minifica de forma suave porque reescribir el marcado corre el riesgo de romper la página. Ajusta tus expectativas (y tu tolerancia al riesgo) al tipo de archivo.

4. Es un acto de apoyo, no el protagonista. Los porcentajes de tamaño de archivo no son porcentajes de Core Web Vitals. La minificación es barata y vale la pena automatizarla, pero en un sitio real, la ganancia de LCP suele estar en las imágenes y en los recursos que bloquean el renderizado. Hazlo y luego pasa a las palancas más grandes.

5. Las herramientas modernas ya lo hicieron. Si envías una compilación de producción desde un empaquetador moderno, tu propio código está minificado. Así que cuando la auditoría aún se active, no asumas que lo olvidaste: mira primero los scripts de terceros, los recursos de los plugins y los bloques en línea.

Hoja de referencia de minificación

Minificar vs. comprimir vs. empaquetar

Orden: minificar → (opcionalmente) empaquetar → comprimir → cachear.

Qué recibe cada tipo de archivo

Herramientas que Google menciona

Datos rápidos

• Auditorías de Lighthouse: unminified-css y unminified-javascript, bajo Oportunidades (informan ahorros potenciales en KiB).
• No hay un porcentaje de ahorro universal — varía según la verbosidad de la fuente, el minificador/opciones y los pasos de compilación previos; mide tus propios archivos. El impacto en CWV suele ser modesto y no está garantizado solo por la reducción de bytes.
• No es un factor de clasificación directo. Alimenta la velocidad de página / Core Web Vitals únicamente.
• Los empaquetadores modernos (Webpack v4+/Terser, Vite, Next.js, esbuild) minifican la salida de producción por defecto.
• Prueba la minificación agresiva de JS en staging antes de publicar.

Herramientas para minificar y diagnosticar

Diagnosticar (¿es siquiera un problema?)

• PageSpeed Insights / Lighthouse — las auditorías “Minify CSS” / “Minify JavaScript” bajo Oportunidades; el punto de partida estándar y de donde llega la mayoría.
• GTmetrix / WebPageTest — muestran las mismas oportunidades de minificación en sus propios informes; útiles para una segunda opinión y contexto de cascada.

Minificadores de herramientas de compilación (el estándar moderno)

• Terser — el minificador de JS popular; el predeterminado en compilaciones de producción de webpack v4+.
• esbuild — empaquetador/minificador extremadamente rápido para JS y CSS.
• Modo de producción de Vite / Next.js / Webpack — minifican la salida automáticamente; normalmente no hay nada que configurar.
• CSSNano y csso — los minificadores de CSS que Google menciona.

Manual / independiente (heredado o puntual)

• HTMLMinifier — para HTML, según la documentación de Google.
• UglifyJS, Google Closure Compiler — los minificadores de JS que Google menciona.
• Minificadores en línea de pegar y listo — adecuados para un caso puntual pequeño y estático; no son un flujo de trabajo para un sitio real.

Auto-minificación de servidor / CDN (sin paso de compilación)

• Módulo PageSpeed para Apache/Nginx — minifica automáticamente las respuestas en el servidor.
• Interruptores de auto-minificación de CDN — muchos CDN ofrecen una configuración de minificación de encendido/apagado.

WordPress (sin necesidad de paso de compilación)

• WP Rocket — “Minify CSS files” / “Minify JavaScript files” en File Optimization.
• Autoptimize — alternativa gratuita que agrega y minifica CSS/JS/HTML.

Errores comunes y mitos

“La minificación es un factor de ranking de Google.” Ningún documento oficial de Google nombra la minificación como una señal de ranking. Reduce el tamaño del archivo, lo que puede ayudar marginalmente a la velocidad de página, que alimenta a Core Web Vitals — una palanca indirecta y menor en el mejor de los casos. Mueller ha planteado que minificar HTML/CSS vale la pena por velocidad, no como una jugada directa de SEO.

“Minificación y compresión son lo mismo.” Son mecanismos diferentes en capas diferentes. La minificación elimina caracteres redundantes del código fuente; la compresión (Gzip/Brotli) recodifica los bytes para el transporte. Aplicas ambas, minificas primero — son complementarias, no intercambiables.

“Minificación y agrupación (bundling) son lo mismo.” La agrupación/concatenación combina archivos para reducir las peticiones HTTP; la minificación reduce el contenido de cada archivo. Los bundlers modernos hacen ambas cosas juntas, por eso se confunden, pero resuelven problemas diferentes.

“Minificar mejorará drásticamente mis Core Web Vitals.” Generalmente exagerado. Los ahorros de tamaño de archivo son reales, pero no hay un porcentaje universal — depende de tus propios archivos — y una reducción de bytes no prueba por sí misma menos ejecución o un cambio medible en Core Web Vitals; eso depende de si el tamaño de transferencia o el tiempo de análisis era realmente tu cuello de botella. El impacto resultante en la velocidad de página suele ser pequeño comparado con la optimización de imágenes o las correcciones de recursos que bloquean el renderizado. Vale la pena hacerlo; rara vez una cura independiente.

“Si uso un framework moderno, todo está manejado, así que puedo ignorar la auditoría.” Mayormente cierto para tu código — pero los scripts de terceros, los recursos de plugins de CMS y los bloques inline escritos a mano a menudo no están cubiertos por tu bundler y aún pueden activar la auditoría de Lighthouse.

“El HTML se minifica igual que CSS/JS — elimina todo lo innecesario.” La minificación de HTML es deliberadamente conservadora (comentarios + espacios en blanco redundantes) porque una reescritura agresiva arriesga romper el marcado renderizado. No esperes ahorros a nivel de CSS/JS, y no recurras a un minificador de HTML agresivo esperando que sea seguro.

“La minificación no puede romper nada, así que solo actívala en producción.” La minificación agresiva de JS ocasionalmente maneja mal sintaxis de casos límite y rompe una funcionalidad. Prueba en staging y haz clic en los elementos interactivos antes de publicar.

Lighthouse aún reporta código no minificado

Síntoma: Tu compilación de producción está minificada, pero la auditoría aún lista ahorros de CSS o JavaScript.

Causa probable: La petición marcada proviene de un plugin, un tercero, un bloque inline o una ruta de asset fuera del bundler.

Corrección y confirmación: Abre la lista de recursos afectados de la auditoría y revisa el iniciador de cada petición. Mueve los assets propios al pipeline de producción; pide al proveedor una compilación minificada o elimina el asset cuando no valga su costo. Vuelve a ejecutar la auditoría y confirma que la petición específica desaparece.

Una funcionalidad de JavaScript se rompe solo en producción

Síntoma: El desarrollo funciona, mientras que el bundle de producción minificado lanza un error o una interacción deja de responder.

Causa probable: La transformación agresiva expuso código que depende de un nombre de función, evaluación insegura, orden de ejecución o una configuración solo de compilación.

Corrección y confirmación: Reproduce con source maps en staging, identifica el bundle fallido más pequeño y desactiva la minificación solo para ese bundle mientras corriges el código o la configuración de la herramienta. Vuelve a activarla y ejercita el flujo afectado de principio a fin.

El tamaño de transferencia apenas cambia

Síntoma: Los archivos fuente son más pequeños después de la minificación, pero el tamaño de transferencia de red cambia poco.

Causa probable: Brotli o Gzip ya comprimen bien los espacios en blanco repetitivos, por lo que el delta en la capa de transporte es menor que el delta del archivo crudo.

Corrección y confirmación: Compara los tamaños decodificado y transferido. Mantén la minificación como una higiene de compilación económica, pero muévete a cuellos de botella más grandes si el waterfall y las Core Web Vitals no mejoran materialmente.

Los visitantes reciben activos de desarrollo sin minificar

Síntoma: El nombre de archivo desplegado, los comentarios o el código fuente legible muestran una compilación de desarrollo.

Causa probable: El comando de despliegue omitió el modo de producción, el HTML referencia la ruta de origen, o una caché obsoleta sirve un manifiesto de activos antiguo.

Corrección y confirmación: Inspecciona la URL y la respuesta de la solicitud en vivo, verifica el comando de compilación de producción y el manifiesto, purga la clave de caché afectada y confirma que una respuesta nueva sirve el activo generado.

El mismo comportamiento con menos caracteres de origen

CSS legible antes:

/* Primary call to action */
.button {
  color: #ffffff;
  margin: 0px 10px 0px 10px;
}

CSS minificado después:

.button{color:#fff;margin:0 10px}

El comentario y los caracteres redundantes han desaparecido, pero la declaración significa lo mismo para el navegador.

JavaScript legible antes:

function doublePrice(price) {
  const multiplier = 2;
  return price * multiplier;
}

JavaScript minificado después:

function doublePrice(e){return 2*e}

La función transformada conserva su salida. Las pruebas de producción son lo que demuestra que las transformaciones más agresivas también preservaron la aplicación que la rodea.

La minificación y la compresión van juntas

Antes: el servidor envía app.js legible sin codificación de contenido.

Después: la compilación emite un app.js minificado, y el servidor envía ese activo con codificación Brotli o Gzip. El primer paso reduce el origen; el segundo reduce los bytes en la red. Ningún paso reemplaza al otro.

Compara la salida cruda y minificada

Terser puede crear un artefacto JavaScript minificado sin sobrescribir el código fuente legible:

npx terser src/app.js --compress --mangle --output dist/app.min.js
wc -c src/app.js dist/app.min.js

Ejecuta la suite de pruebas de producción contra el bundle generado antes del despliegue. El recuento de bytes demuestra que el artefacto cambió; las pruebas funcionales demuestran que el comportamiento no lo hizo.

Inventario de tamaños transferidos y decodificados en DevTools

Pega esto en la Consola después de una carga de página en frío. Muestra los bytes de JavaScript y CSS tal como el navegador los recibió y decodificó:

performance.getEntriesByType('resource')
  .filter(r => ['script', 'link'].includes(r.initiatorType))
  .map(r => ({
    resource: new URL(r.name).pathname,
    transferred: r.transferSize,
    decoded: r.decodedBodySize,
  }))
  .sort((a, b) => b.decoded - a.decoded);

La diferencia entre decoded y transferred refleja la compresión del transporte; la minificación cambia el activo decodificado en sí.

Detecta artefactos de desarrollo en la salida desplegada

Esta comprobación del árbol de origen encuentra referencias de mapas de origen de JavaScript y marcadores de desarrollo comunes que merecen revisión antes de publicar:

grep -RInE 'sourceMappingURL|process\.env\.NODE_ENV.{0,20}development' dist

Una coincidencia es una pista de investigación, no una prueba automática de que la minificación falló.

Equivalencia de activos de producción

Prueba a ejecutar: Compila las variantes legible y minificada en staging, luego ejecuta las mismas pruebas unitarias, de integración y de flujo de usuario crítico contra la salida minificada.

Resultado esperado: Las pruebas y el comportamiento visible coinciden mientras el archivo CSS o JavaScript generado es más pequeño.

Interpretación de fallo: Una opción del minificador cambió el comportamiento observable o expuso una suposición solo de compilación que debe corregirse.

Ventana de monitoreo: Ejecuta en cada compilación de producción y haz una prueba de humo inmediatamente después del despliegue.

Disparador de reversión: Revierte si una interacción crítica, una ruta de renderizado o la tasa de errores regresan en la compilación minificada.

Comprobación de recursos desplegados

Prueba a ejecutar: Abre la auditoría de minificación de Lighthouse en vivo e inspecciona las respuestas CSS/JS exactas nombradas en su lista de recursos afectados.

Resultado esperado: Los activos de producción propios están ausentes de la lista de recursos sin minificar; cualquier elemento restante tiene un propietario identificado de terceros o heredado.

Interpretación de fallo: Una ruta de origen omitió la compilación, un plugin emitió un archivo sin procesar, o HTML/caché obsoleto aún referencia un activo de desarrollo.

Ventana de monitoreo: Comprueba después de cada cambio en el pipeline de activos o en el despliegue.

Disparador de reversión: Revierte un cambio en el pipeline si comienza a servir artefactos de desarrollo o rompe las URLs de producción con cache-busting.

Comprobación de la pila de transporte

Prueba a ejecutar: Compara los tamaños decodificado y transferido para la respuesta minificada en vivo e inspecciona su codificación de contenido.

Resultado esperado: El cuerpo decodificado refleja el artefacto minificado y la transferencia usa Brotli o Gzip donde el servidor y el cliente lo soportan.

Interpretación del fallo: La minificación o compresión falta en su propia capa; una no demuestra la otra.

Ventana de monitoreo: Verifica inmediatamente después de cambios en la configuración de CDN, servidor o compilación.

Disparador de reversión: Revierte si la configuración sirve activos no válidos o causa una regresión repetible en el tamaño de transferencia o funcional.

Recursos que valen tu tiempo

Mis escritos relacionados

• Qué es el Largest Contentful Paint (LCP) y cómo mejorarlo — mi guía más clara sobre minificación está aquí, en una sección de “hacer archivos más pequeños”: minifica tu CSS, minifica tu JS, elimina lo que no se usa.
• WordPress SEO: 20 Tips and Best Practices — el lado práctico para CMS: los interruptores de optimización de archivos de WP Rocket, Autoptimize como alternativa gratuita y la advertencia de probar en staging.
• Google PageSpeed Insights para profesionales de SEO y desarrolladores — donde “minificar código” aparece como una de las cosas que analiza PSI, y el informe del que provienen la mayoría de los lectores.
• Guía para principiantes sobre SEO técnico — donde la velocidad de página y la minificación encajan en el panorama general.

Mis charlas

• Cómo funciona la búsqueda (SlideShare) — rastreo, renderizado, indexación y clasificación, incluido dónde encaja el rendimiento del frontend. (Se aplica mi descargo de responsabilidad habitual: “This is my understanding of systems… not going to be 100% complete or accurate.” (traducción) «Esta es mi comprensión de los sistemas… no va a ser 100 % completa o precisa».)

Oficial

• Minificar CSS y Minificar JavaScript (Google Lighthouse) — las dos auditorías y su guía específica por plataforma.
• Minificar recursos (HTML, CSS y JavaScript) (Google PageSpeed Insights) — el documento heredado que menciona la minificación de HTML y herramientas específicas.

Del resto de la industria

• Minificación y SEO: una guía breve (OnCrawl) — la pieza existente más cercana sobre “minificación para SEO”; sólida en la desambiguación entre minificación, compresión y concatenación.
• Cómo minificar CSS para mejorar el rendimiento web (Cloudflare) — definiciones en lenguaje sencillo y el matiz por tipo de archivo (la minificación de HTML es más superficial que la de CSS/JS).
• Minificar JavaScript y CSS (GTmetrix) — solución de problemas activada por auditorías y un resumen de herramientas (Closure Compiler, JSMin, YUI Compressor).
• Cómo minificar JavaScript — herramientas y métodos recomendados (Kinsta) — un recorrido centrado en JS de cómo se ve el código minificado y las herramientas.
• Google considera que conviene estudiar la compresión de HTML y CSS (Search Engine Roundtable) — cobertura del comentario de John Mueller de que minificar HTML/CSS puede valer la pena para el tamaño de archivo, enmarcado como velocidad/UX más que como una palanca de clasificación.
• r/TechSEO — la comunidad para depurar rendimiento y Core Web Vitals.

Ponte a prueba: Minificación

Cinco preguntas rápidas sobre lo que la minificación hace y no hace. Elige una respuesta para cada una y luego comprueba.

Registro de cambios