Optimizar el peso del email: HTML, imágenes y clipping de Gmail

Cómo reducir el peso de un email HTML para evitar el clipping de Gmail (102KB), minificar HTML, comprimir imágenes y mejorar tiempos de render en clientes.

El peso del email tiene impacto directo en deliverability, render y experiencia del usuario. Gmail recorta cualquier mensaje cuyo HTML supere aproximadamente 102KB, lo que rompe píxeles de tracking y CTAs por debajo del corte. Outlook desktop tarda más en abrir mensajes pesados. Y los clientes móviles en redes lentas pierden interés si las imágenes tardan en cargar. Reducir el peso es una de las optimizaciones con mejor relación coste-beneficio en email.

Las tres dimensiones del peso

Cuando hablamos de “peso del email” nos referimos a tres cosas distintas que conviene medir por separado.

Peso del HTML

Es lo que mide Gmail para decidir si aplicar clipping. Incluye:

• El HTML escrito por ti.
• Los estilos CSS embebidos.
• Las variables sustituidas (nombres, productos, links de tracking).
• El código que el ESP añade automáticamente (píxeles, wrappers, footer legal).
• Headers y MIME envueltos.

Sin imágenes ni adjuntos. Solo el texto del cuerpo.

Peso de las imágenes

Las imágenes externas referenciadas por URL no cuentan para el clipping de Gmail, pero sí para el tiempo de render y para el peso total que el cliente descarga. Si abusas, el usuario en 4G puede tardar segundos antes de ver tu CTA.

Peso total del email

La suma de HTML + imágenes + adjuntos. Idealmente < 600KB para emails marketing, < 1MB en casos especiales. Pasarse de 1MB es señal de que conviene rediseñar.

El problema de Gmail clipping

Qué hace Gmail

Cuando el HTML supera ~102KB, Gmail muestra el contenido truncado y un enlace “View entire message” que abre la versión completa en una pestaña aparte. Las consecuencias prácticas:

• El píxel de tracking, que suele ir al final, no se carga: aperturas no se cuentan.
• CTAs por debajo del corte requieren un clic extra para verse.
• El List-Unsubscribe en cabeceras sigue funcionando, pero el del cuerpo se pierde.
• Da impresión de “email roto”.

Por qué se llega a 102KB

Casos típicos:

• Plantilla con CSS inline en cada celda (el inline duplica reglas en docenas de elementos).
• Imágenes embebidas en base64 dentro del <img>.
• Frameworks completos (Bootstrap, etc.) sin purgar.
• Comentarios y código no usado.
• Variables muy largas (URLs de tracking de 200-300 caracteres por enlace, multiplicadas por todos los enlaces).
• Dynamic content para cada destinatario que multiplica el contenido base.

Cómo medir

$ wc -c email.html
   95342 email.html

O con node:

$ node -e "console.log(require('fs').statSync('email.html').size)"
95342

Hazlo con la versión final, tras renderizar variables y aplicar todos los wrappers del ESP. Algunos ESP permiten descargar el HTML enviado a un destinatario concreto: usa eso para medir lo que de verdad llega.

Minificación del HTML

Qué se puede minificar

• Espacios en blanco superfluos entre etiquetas.
• Indentación.
• Comentarios HTML que no sean condicionales de Outlook.
• Atributos vacíos (alt="" no, ese sí se queda).
• Comillas redundantes en algunos atributos (con cuidado).

Qué NO tocar

• Conditional comments <!--[if mso]> y similares: son críticos para Outlook.
• Inline styles necesarios en cada celda.
• Espacios dentro de <pre> o atributos.
• Texto del usuario.

Herramientas

• html-minifier-terser con --conservative-collapse y preservando conditional comments.
• mjml-cli si maquetaste con MJML (genera HTML ya razonablemente compacto).
• Plugins de Webpack/Vite si el email se compila desde un build.

Configuración tipo de html-minifier-terser:

{
  "collapseWhitespace": true,
  "removeComments": false,
  "ignoreCustomComments": [
    "^\\[if\\s",
    "<!\\[endif\\]"
  ],
  "minifyCSS": true,
  "removeEmptyAttributes": false,
  "preserveLineBreaks": false
}

removeComments: false y ignoreCustomComments son clave: borrar los conditional rompería Outlook.

Limpieza de CSS

Un email rara vez usa todo el CSS que tiene. Estilos copiados de plantillas previas, clases que se usaron en una versión anterior y reglas duplicadas suman KB innecesarios.

Cómo identificar lo no usado

• Tools como purgecss adaptadas a HTML estático.
• Auditoría manual rápida: para cada clase, buscarla en el HTML.
• Analizar el <style> y eliminar reglas que no se aplican a ningún elemento.

Cuidado con el dynamic content: si hay reglas que solo se usan en variantes condicionales del email, no las elimines.

Inline styles vs head styles

El balance entre inline (cada estilo en cada elemento) y head (un solo bloque <style>) afecta al peso:

• Inline duplica los mismos estilos en muchos elementos.
• Head es más compacto, pero algunos clientes no lo respetan.

Una práctica eficiente: declarar la mayoría de estilos en <head> y aplicar inline solo lo crítico (color de texto en celdas que Gmail saneará). Esto mantiene la compatibilidad y reduce el peso.

Compresión de imágenes

Formatos

• JPEG con compresión 75-85 para fotografías.
• PNG con paleta optimizada para gráficos con transparencia.
• WebP si el cliente lo soporta (Apple Mail, Gmail web sí; Outlook desktop no).
• GIF solo si necesitas animación (y considera si vale la pena, son pesados).

Herramientas

• mozjpeg o imagemin con plugins.
• optipng o pngquant para PNG.
• cwebp para WebP.
• ImageOptim en Mac, Squoosh en navegador.

Una imagen de cabecera de 800px de ancho en JPEG calidad 80 debería pesar entre 60 y 120KB. Si pesa 400KB, hay que comprimirla.

Tamaño correcto

Las imágenes deben servirse al tamaño que se van a ver, no al doble por “calidad”. El cliente de email no va a hacer zoom: lo que se ve es lo que pesa.

• Cabecera principal: 600-1200px de ancho según display.
• Producto en grilla: 300-600px.
• Iconos sociales: 24-48px.

Evita servir imágenes de 2000px y dejar que el cliente las escale: pesan mucho más sin aportar.

Servir desde CDN

Imágenes en CDN se cargan en paralelo, se cachean y soportan compresión Brotli/gzip. El correo no se beneficia de la cache entre usuarios distintos, pero sí de la cercanía geográfica del CDN al destinatario.

Evita totalmente imágenes en base64 dentro del HTML: cuentan para el peso del HTML y se cuentan para el clipping.

Optimizar el ratio texto/HTML

Los filtros antispam analizan el contenido. Un email con 3 líneas de texto y 90KB de markup levanta sospechas. Buscar:

• Al menos un 40-50 % del peso del HTML correspondiendo a contenido textual.
• Estructura HTML proporcional al contenido. Una landing extensa justifica más markup que un envío con dos frases.
• Evitar bloques decorativos masivos sin texto.

Si tu email es muy “imagen-pesado” con poco texto, suma copia visible que aporte valor. Mejora deliverability y accesibilidad.

Optimización en envíos masivos

Variables y dynamic content

Cada destinatario recibe una versión “renderizada” del email. Si tu plantilla tiene 60KB y por destinatario añades 5-10KB de personalización (productos recomendados, nombre, links de tracking únicos), llegas a 70KB. Suma el wrapper del ESP y puedes acercarte al límite.

Optimiza:

• Acortadores de URL sensatos (no acumular parámetros UTM duplicados).
• Personalización proporcional: si el email “personalizado” tiene 50 productos por destinatario, repensar.
• Dynamic content que se renderiza en servidor, no condicionales en el HTML que se envían siempre.

Precompiled vs runtime

Algunos ESP precompilan el HTML por destinatario y reducen wrappers. Otros aplican wrappers genéricos. Si el ESP añade mucho footer técnico (links de baja, branding, tracking), parte del presupuesto KB se va ahí.

Validación tras minificar

Tras la minificación, revisa el render en al menos:

• Outlook desktop Windows (los conditional comments deben seguir funcionando).
• Gmail web (HTML interno aplicado correctamente).
• Apple Mail iOS y macOS (CSS moderno respetado).
• Yahoo y Outlook.com web.

Más detalle de qué revisar en cada cliente en la guía de compatibilidad cross-client.

Errores frecuentes

Pasar el límite por personalización extrema

El HTML “fuente” mide 80KB, pero la personalización por destinatario lo lleva a 110KB. Mide siempre la versión final.

Eliminar conditional comments al minificar

El minificador agresivo borra <!--[if mso]>. Outlook desktop deja de mostrar lo que dependía de eso. Configura siempre el minificador para preservarlos.

Imágenes en base64

Aunque parecen prácticas para “auto-contenidos”, inflan el HTML y son la causa más común de clipping en emails con muchas imágenes pequeñas.

Frameworks sin purgar

Cargar Bootstrap completo en el <style> añade 100KB de reglas no usadas. Para email, mejor escribir el CSS necesario o usar herramientas específicas.

No medir tras render

Algunos equipos miden el HTML “fuente” antes de variables. La versión real es siempre mayor.

Sustituir HTML denso por imágenes

Tentación: meter todo en una imagen grande y reducir HTML. Resultado: imagen pesada, mal alt text, render variable y filtros antispam más estrictos.

El presupuesto razonable

Como guía:

• HTML final tras render: < 90KB. Mejor si te quedas en 60-70KB.
• Imágenes total: < 500KB para marketing visual; < 100KB para transaccional sobrio.
• Total del email: idealmente < 600KB.

Si tu plantilla original viene de un editor visual del ESP, comprueba el resultado. Algunos editores generan HTML extremadamente verboso (60-80 % de overhead vs equivalente escrito a mano).

La pregunta clave

Antes de optimizar al milímetro, pregúntate qué quieres conseguir. Para emails transaccionales (recibos, OTPs), 30KB sobra. Para newsletters editoriales con muchas piezas, 70-80KB es razonable. Para campañas masivas con personalización, controla el peso total tras renderizar.

La optimización del peso es un proceso continuo: cada cambio en la plantilla, cada nuevo bloque, cada actualización del wrapper del ESP puede mover el contador. Incluir una medición en el flujo de QA evita que el clipping aparezca tras un envío real, cuando ya no hay forma de corregir.

Recursos relacionados

Si quieres profundizar, prueba estas herramientas gratuitas: Domain Health, mail tester, validador SPF y validador DMARC.

¿Necesitas que alguien lleve tu canal de email entero? Abalola Mail es la agencia de email marketing para ecommerce de Abalola para ecommerce: estrategia, producción y operación del stack sobre Klaviyo, Mailchimp o Brevo.