Una página convertida puede ser tan rápida como una creada a mano o notablemente más lenta, según algunas decisiones que se tomen durante y después de la conversión.
Prioriza los widgets nativos frente a los bloques HTML
El factor más determinante. Una página colocada dentro de un gran widget HTML arrastra consigo toda su hoja de estilos original, incluidas reglas para elementos que no están en la página. El modo de componentes nativos produce widgets reales cuyos estilos Elementor genera y almacena en caché por página, de modo que se envía mucho menos CSS sin usar y, además, obtienes una página editable.
Decide qué hacer con la hoja de estilos original
Conservar los estilos en línea es útil durante la conversión, porque es lo que permite medir correctamente los estilos basados en clases. Pero una vez que los widgets incorporan sus propios ajustes, el bloque de CSS sobrante al principio de la página suele ser redundante. Prueba a eliminarlo y comprueba el diseño: si nada se mueve, acabas de borrar un buen trozo de peso muerto.
Las imágenes merecen la mayor atención
- Sube imágenes reales a la biblioteca de medios en lugar de incrustar URLs de datos. Una imagen en Base64 no se puede redimensionar, cachear por separado ni cargar de forma diferida, y además infla el propio HTML de la página.
- Deja que WordPress sirva tamaños responsive en lugar de forzar un único tamaño grande en todas partes.
Qué hace realmente la opción de optimización de imágenes
Esta opción es más limitada de lo que sugiere su nombre, y conocer sus límites te evita esperar algo que no va a hacer.
Solo se ejecuta en modo de alta fidelidad y únicamente sobre imágenes de datos en Base64 —PNG, JPEG o WebP— que superen aproximadamente los 135 KB. Esas imágenes se decodifican, se reducen para que su lado más largo sea como máximo de 2560 px y se vuelven a codificar. La vista de resultados informa de cuántas se procesaron y cuánto espacio se ahorró.
Lo que no hace: no toca las imágenes referenciadas por URL, porque son archivos en un servidor que la herramienta no tiene por qué reescribir. Y en el modo de componentes nativos no se ejecuta en absoluto: allí las imágenes Base64 se convierten en espacios vacíos etiquetados para que los rellenes desde la biblioteca de medios, lo cual es de todas formas el mejor resultado.
Así que el resumen honesto es que esta opción rescata una situación concreta: una importación de alta fidelidad de una página cuyas imágenes estaban todas incrustadas, normalmente una generada por una herramienta de IA. Si tus imágenes son URLs normales, la opción es irrelevante y la optimización real ocurre donde debe ocurrir: en tu biblioteca de medios, con WordPress generando tamaños responsive.
Vigila la profundidad de anidamiento
Los árboles de contenedores profundos no solo son incómodos de editar: cada nivel es otro nodo del DOM y otro conjunto de reglas CSS generadas. Si el mapa de estructura muestra una profundidad de siete u ocho, simplifica el origen o establece una raíz de copia más profunda en el árbol. Una salida más plana es más rápida y más fácil de mantener.
Fuentes
Una página convertida nombra las fuentes que usaba el original. Si no son fuentes que tu sitio ya carga, regístralas correctamente o cambia a la tipografía del sitio para que la página use fuentes que ya estás sirviendo. Lo que quieres evitar es cargar una segunda familia tipográfica para una sola sección importada.
Reincorpora el comportamiento de forma nativa
Los scripts se eliminan durante la conversión, lo cual es bueno tanto para el rendimiento como para la seguridad. Cuando reconstruyas deslizadores, pestañas o contadores, usa los widgets propios de Elementor en lugar de volver a pegar scripts de terceros, ya que forman parte del paquete que estás cargando.
Por qué una página convertida no está automáticamente inflada
Es razonable la preocupación de que una conversión automatizada entierre la página en ajustes y de que todos esos ajustes se conviertan en CSS. Hay dos cosas que evitan que eso ocurra.
Primero, los valores responsive se escriben solo donde difieren de los valores de escritorio. Un contenedor con el mismo padding en todos los anchos recibe un único valor de padding, no tres. En una página con sesenta widgets, esa es la diferencia entre una hoja de estilos ligera y una que arrastra dos tercios de reglas redundantes.
Segundo, los envoltorios que se puede demostrar que no hacen nada se eliminan en lugar de convertirse. Todo contenedor que sobrevive es un <div> real con sus propias reglas generadas, de modo que descartar los que no tienen efecto estilístico elimina tanto un nodo del DOM como su CSS.
Lo que nada de eso puede arreglar es un marcado de origen que ya era profundo desde el principio. El conversor refleja tu HTML; no lo rediseña. Un origen de siete niveles produce una página pesada por mucho cuidado que se ponga en cada nivel, y por eso aplanar el origen vale más que cualquier limpieza posterior a la importación.
Mide y luego limpia
Pasa la página por una prueba de velocidad antes y después de tu pasada de limpieza. Normalmente las mejoras vienen de tres lugares: eliminar el bloque de hoja de estilos redundante, reemplazar imágenes sobredimensionadas y aplanar un árbol excesivamente anidado. Ninguna lleva mucho tiempo y, en conjunto, suelen explicar la mayor parte de la diferencia.
Observa las cifras correctas. El peso total de la página y el Largest Contentful Paint responden al trabajo con las imágenes. El Cumulative Layout Shift responde a que las imágenes tengan dimensiones explícitas: un marcador de posición que rellenaste desde la biblioteca de medios las tiene, mientras que una imagen Base64 a menudo no. Y el recuento de nodos del DOM, que la mayoría de informes muestra y la mayoría de la gente pasa por alto, es el que te dice si el anidamiento está bajo control.