Una página puede verse rápida en nuestro computador y seguir ofreciendo una experiencia deficiente a parte de sus visitantes. También puede obtener 95 o 100 puntos en una prueba de Lighthouse y, aun así, presentar problemas de Core Web Vitals WordPress con usuarios reales.

Por eso, optimizar rendimiento no debería empezar instalando otro plugin de caché. Primero debemos identificar qué métrica falla, qué elemento está provocando el problema y qué cambio puede corregir esa causa.

Google utiliza actualmente tres Core Web Vitals: Largest Contentful Paint, Interaction to Next Paint y Cumulative Layout Shift. Juntas evalúan carga percibida, capacidad de respuesta y estabilidad visual. Para considerar una experiencia buena, Google recomienda evaluar el percentil 75 de las visitas.

¿Qué son realmente las Core Web Vitals?

Las tres métricas actuales son:

CLS no se mide en segundos. Es una puntuación de estabilidad visual.

LCP: Largest Contentful Paint

Pregunta sencilla:

¿Cuánto tarda en aparecer el contenido principal?

En WordPress puede ser una imagen hero, una imagen destacada, un banner o incluso un bloque grande de texto.

INP: Interaction to Next Paint

Pregunta:

¿Qué tan rápido responde la página cuando alguien interactúa?

Puede verse afectado al abrir un menú, usar filtros, escribir en un formulario, pulsar un botón o interactuar con widgets.

INP reemplazó oficialmente a FID como Core Web Vital el 12 de marzo de 2024. Cualquier guía que siga presentando FID, LCP y CLS como las tres métricas actuales está desactualizada.

CLS: Cumulative Layout Shift

Pregunta:

¿Cuánto se mueve inesperadamente la página mientras la estamos utilizando?

Ejemplos típicos:

• Una imagen aparece y empuja el texto.
• Un banner se inserta arriba después de cargar.
• Una fuente cambia las dimensiones del contenido.
• Un mapa, anuncio o widget ocupa espacio tarde.

PageSpeed 100 no es lo mismo que aprobar Core Web Vitals

PageSpeed Insights muestra dos tipos de información diferentes.

Datos de campo

Proceden del Chrome User Experience Report, CrUX y representan experiencias reales de usuarios de Chrome.

Google utiliza aproximadamente los 28 días anteriores y reporta el percentil 75 de las métricas.

Datos de laboratorio

Proceden de Lighthouse y representan una prueba controlada y simulada.

Son muy útiles para diagnosticar problemas y comprobar cambios inmediatamente, pero no son un historial de lo que experimentaron tus usuarios.

Por eso:

Lighthouse 100 ≠ Core Web Vitals reales aprobadas.

Y también:

Lighthouse 80 ≠ necesariamente mala experiencia para todos tus usuarios.

PageSpeed Insights combina precisamente CrUX para datos reales y Lighthouse para diagnóstico.

Google tampoco utiliza Core Web Vitals como una señal aislada que garantice una posición concreta. La experiencia de página incluye más factores y debe analizarse junto con relevancia, contenido, HTTPS y usabilidad.

Datos de campo vs. datos de laboratorio

Necesitamos los dos. Los datos reales nos dicen qué está ocurriendo y el laboratorio nos ayuda a investigar por qué.

TTFB no es una Core Web Vital, pero puede afectar LCP

TTFB significa Time to First Byte y mide cuánto tarda el navegador en comenzar a recibir la respuesta del servidor.

No es una Core Web Vital.

Sin embargo, si el servidor responde lentamente, el HTML llega tarde y también empiezan tarde las solicitudes de CSS, fuentes, JavaScript e imágenes. Por eso un TTFB alto puede contribuir a un LCP deficiente.

No significa que mejorar TTFB garantice mejorar LCP: primero debemos identificar dónde está realmente el cuello de botella.

Core Web Vitals WordPress: 9 optimizaciones esenciales

1. Mide primero y localiza qué plantilla está fallando

Problema que resuelve: optimizar a ciegas.

Puede afectar: LCP, INP y CLS.

Antes de instalar plugins o cambiar configuraciones, analiza páginas representativas:

• Inicio.
• Página de servicio.
• Entrada del blog.
• Archivo.
• Producto.
• Checkout, si existe ecommerce.

Después revisa Search Console. Su informe Core Web Vitals utiliza datos reales de CrUX, separa móvil y escritorio y agrupa páginas que comparten características similares.

Esto es especialmente útil en WordPress: si veinte páginas usan la misma plantilla de Elementor y esa plantilla provoca CLS, corregir el template puede mejorar todo el grupo.

Qué hacer: registra los valores iniciales y la métrica problemática.

Precaución: no optimices únicamente la home.

Cómo comprobar: PageSpeed Insights + Search Console + Lighthouse, antes y después.

2. Mejora servidor, hosting y tiempo de respuesta

Problema que resuelve: respuesta inicial lenta.

Puede afectar: principalmente LCP.

WordPress identifica el entorno de hosting como uno de los factores importantes de rendimiento. CPU, memoria, base de datos, versión de PHP, almacenamiento, ubicación del servidor y carga disponible pueden influir.

Antes de migrar de hosting, comprueba:

• TTFB.
• Uso de CPU y memoria.
• Errores.
• Límites de procesos.
• Versión de PHP.
• Base de datos.
• Caché del servidor.

Un servidor lento retrasa la cadena completa que necesita el navegador para mostrar el contenido.

Ejemplo: si el HTML tarda demasiado en llegar, optimizar una imagen del hero puede no ser suficiente.

Precaución: no culpes automáticamente al hosting. Un plugin muy pesado también puede generar respuestas lentas.

Cómo verificar: compara TTFB, tiempos de servidor y LCP antes y después.

3. Implementa una estrategia de caché adecuada

Problema que resuelve: generar repetidamente contenido que podría reutilizarse.

Puede afectar: TTFB y, de forma indirecta, LCP.

Existen varias capas:

Page cache

Guarda páginas ya generadas para evitar reconstruirlas en cada visita.

Browser cache

Permite que imágenes, CSS o JavaScript se reutilicen desde el navegador.

Object cache

Puede reducir consultas repetidas a la base de datos. WordPress menciona Redis y Memcached como tecnologías habituales cuando el hosting ofrece soporte.

No todos los sitios necesitan las mismas capas.

WooCommerce, usuarios autenticados, carrito y checkout requieren especial cuidado porque contienen información dinámica.

Error frecuente: instalar dos o tres plugins de caché intentando “sumar velocidad”.

Precaución: evita cachear indiscriminadamente páginas dinámicas.

Cómo verificar: revisa TTFB, comportamiento del carrito/formularios y carga de páginas antes y después.

4. Optimiza imágenes y, sobre todo, el elemento LCP

Problema que resuelve: recursos visuales excesivamente pesados o descubiertos tarde.

Afecta: principalmente LCP.

Una fotografía de 4000 × 3000 píxeles no necesita descargarse completa si se muestra a 600 × 450.

Revisa:

• Dimensiones.
• Peso.
• Compresión.
• WebP o AVIF cuando convenga.
• Imágenes responsive.
• Recurso realmente mostrado en cada dispositivo.

Después identifica cuál es el elemento LCP.

Si es la imagen principal, debe descubrirse pronto. web.dev recomienda evitar que el recurso LCP dependa innecesariamente de JavaScript o CSS para ser descubierto y, cuando corresponde, priorizar su descarga.

En Elementor existen actualmente funciones de Optimized Image Loading que intentan detectar y priorizar imágenes importantes y evitar lazy loading en imágenes visibles inicialmente. Elementor también ofrece Image Optimization como herramienta separada para comprimir y convertir imágenes.

Error frecuente: aplicar lazy loading a la imagen hero.

Precaución: tampoco debemos marcar diez imágenes como prioritarias.

Cómo verificar: revisa en Lighthouse cuál es el elemento LCP y vuelve a medir después del cambio.

5. Utiliza lazy loading solo donde aporta valor

Problema que resuelve: descargar recursos que el usuario todavía no necesita.

Puede afectar: LCP positiva o negativamente, según dónde se utilice.

Lazy loading funciona muy bien para:

• Imágenes debajo del primer viewport.
• Galerías largas.
• Iframes.
• Videos.
• Contenido inferior.

Pero no debería retrasar indiscriminadamente:

• Logo visible.
• Hero.
• Imagen LCP.
• Elementos principales del primer viewport.

El objetivo es muy sencillo:

retrasar lo que todavía no necesitamos, no retrasar lo primero que queremos ver.

Elementor documenta lazy loading para distintos widgets y actualmente evita aplicarlo a ciertas imágenes visibles inicialmente cuando utiliza su optimización automática.

Precaución: prueba cada plantilla, especialmente móvil.

Cómo verificar: confirma que el LCP no empeore y que las imágenes inferiores sigan cargando correctamente.

6. Reduce JavaScript innecesario para mejorar INP

Problema que resuelve: navegador ocupado cuando el usuario intenta interactuar.

Afecta: principalmente INP.

JavaScript debe descargarse, analizarse y ejecutarse. Cuando mantiene ocupado el hilo principal durante demasiado tiempo, la respuesta a un clic, menú o formulario puede retrasarse.

web.dev identifica las tareas largas y la ejecución de scripts como causas frecuentes de latencia en interacciones.

En WordPress conviene auditar:

• Plugins.
• Addons de Elementor.
• Chatbots.
• Sliders.
• Popups.
• Pixels.
• Scripts publicitarios.
• Trackers.
• Widgets sociales.
• Mapas y embeds.

No significa eliminar Analytics o las herramientas comerciales necesarias solo para mejorar PageSpeed.

La pregunta correcta es:

¿el valor empresarial de este script justifica su coste de rendimiento?

async, defer y delay

Son estrategias diferentes.

defer busca posponer la ejecución hasta que el HTML esté procesado.

async descarga independientemente y ejecuta cuando está disponible.

Algunas herramientas ofrecen delay hasta que exista interacción.

No recomendamos “retrasar todo JavaScript” sin pruebas: puede romper menús, ecommerce, consentimiento, formularios y analítica.

Cómo verificar: prueba las interacciones reales además de ejecutar Lighthouse.

7. Simplifica DOM y estructuras innecesariamente complejas de Elementor

Problema que resuelve: exceso de elementos HTML y trabajo de renderizado.

Puede afectar: INP y rendimiento general.

Una página Elementor puede acumular:

• Containers.
• Widgets dentro de widgets.
• Secciones repetidas.
• Elementos ocultos.
• Addons.
• Versiones duplicadas para escritorio y móvil.

Un DOM más complejo aumenta el trabajo de cálculo de estilos, layout y renderizado.

Elementor ha eliminado progresivamente wrappers innecesarios; desde Elementor 3.19 varias optimizaciones de DOM forman parte del Core del constructor.

Recomendamos:

• Containers simples.
• Menos nesting.
• Reutilizar estilos.
• Eliminar widgets innecesarios.
• Resolver responsive sin duplicar secciones completas cuando sea posible.
• Revisar addons que apenas se utilizan.

No existe un número mágico universal de nodos DOM.

Precaución: simplificar una estructura existente puede afectar CSS personalizado.

Cómo verificar: compara interactividad, complejidad y funcionamiento responsive después del cambio.

8. Corrige las causas reales de CLS

Problema que resuelve: contenido que “salta” mientras carga.

Afecta: CLS.

Las causas habituales incluyen:

• Imágenes sin dimensiones.
• Videos.
• Iframes.
• Mapas.
• Banners.
• Cookie notices.
• Publicidad.
• Popups.
• Fuentes.
• Contenido AJAX.
• Header que cambia de altura.

Una de las mejores defensas es reservar el espacio desde el inicio. web.dev recomienda establecer dimensiones explícitas o relaciones de aspecto para imágenes y otros elementos.

Mal: aparece un banner tres segundos después y empuja toda la página.

Mejor: el navegador conoce el espacio que ocupará desde el primer render.

No todo movimiento es CLS: las animaciones intencionales correctamente ejecutadas no equivalen automáticamente a un layout shift inesperado.

Cómo verificar: observa el informe CLS de herramientas de desarrollo y revisa especialmente móvil.

9. Reduce plugins, terceros y recursos cuyo coste no se justifica

Problema que resuelve: acumulación progresiva de código.

Puede afectar: las tres métricas.

WordPress recomienda revisar extensiones innecesarias porque cada plugin puede añadir trabajo de servidor, CSS, JavaScript, consultas o recursos externos.

Audita:

• Plugins.
• Addons Elementor.
• Fuentes.
• Chats.
• Analytics duplicado.
• Pixels.
• Mapas.
• Videos.
• Social widgets.
• Sliders.
• Animaciones.

Para cada recurso pregunta:

¿aporta una función que realmente necesita el negocio?

Eliminar código inútil suele ser más sostenible que añadir otra capa de optimización encima.

Precaución: no desactives plugins críticos directamente en producción.

Utiliza backup, staging y pruebas.

Cómo verificar: compara la misma plantilla antes y después y confirma que no desaparecieron funciones comerciales.

LCP en WordPress: causas habituales

No significa que todos los sitios tengan estos problemas.

INP en WordPress: causas habituales

Entre los sospechosos habituales encontramos JavaScript pesado, tareas largas del hilo principal, plugins, filtros complejos, menús, addons Elementor, chat, trackers y scripts externos.

INP se construye con interacciones de usuarios reales. Lighthouse puede utilizar métricas de laboratorio como Total Blocking Time para ayudarnos a encontrar problemas, pero TBT e INP no son la misma métrica.

CLS en WordPress: causas habituales

Revisa especialmente:

• Imágenes sin tamaño reservado.
• Fuentes.
• Sticky headers.
• Cookie banners.
• Ads.
• Popups.
• Embeds.
• Videos.
• Mapas.
• Contenido AJAX.

En Elementor, un header que cambia de altura al volverse sticky o un hero sin relación de aspecto estable puede provocar movimientos visibles.

Fuentes web y rendimiento

Varias familias tipográficas con muchos pesos añaden solicitudes y archivos.

Revisa:

• Qué pesos utilizas realmente.
• Preload únicamente cuando tenga sentido.
• Estrategia de font-display.
• Icon fonts enormes para utilizar tres iconos.

Alojar una fuente localmente no es automáticamente mejor. También debemos revisar licencia, CDN, caché y configuración.

CSS: qué conviene optimizar

Evalúa:

• CSS no utilizado.
• CSS crítico.
• Hojas cargadas por plugins.
• Dependencias innecesarias.

No recomendamos combinar todo el CSS en un único archivo por norma.

HTTP/2 y HTTP/3 permiten multiplexación, por lo que algunas recomendaciones antiguas de concatenación extrema han perdido relevancia. Incluso la documentación de rendimiento de WordPress señala que ciertas técnicas heredadas de HTTP/1.x ya no son necesarias de la misma forma.

La prioridad debería ser menos código y mejor carga, no una receta universal.

CDN: cuándo puede ayudar

Un CDN puede servir recursos desde ubicaciones más cercanas a los visitantes y disminuir carga del servidor.

WordPress lo plantea como una opción especialmente útil para contenido estático y usuarios distribuidos geográficamente.

Pero un CDN no corrige:

• JavaScript excesivo.
• DOM enorme.
• CLS.
• Plugin lento.
• Una mala estructura Elementor.

Object cache: cuándo tiene sentido

Un object cache persistente puede reducir consultas repetidas a la base de datos.

Puede aportar especialmente en:

• WooCommerce.
• Portales.
• Sistemas dinámicos.
• Alto tráfico.

Redis o Memcached requieren soporte real del servidor. No tiene sentido instalar simplemente un plugin Redis si el hosting no dispone del servicio correspondiente.

Base de datos WordPress

Revisiones, transients, cron, opciones autoload y residuos de plugins eliminados pueden generar trabajo adicional.

Pero limpiar tablas manualmente sin backup ni conocimiento puede causar problemas mucho mayores que una mejora marginal.

Una base de datos ordenada puede beneficiar procesos de servidor. No garantiza por sí sola que LCP, INP y CLS pasen a verde.

Performance Lab de WordPress

Performance Lab es desarrollado por el WordPress Performance Team y funciona como colección de funciones relacionadas con rendimiento que pueden probarse antes de que algunas lleguen al núcleo.

Actualmente incluye proyectos como Embed Optimizer, Enhanced Responsive Images, Image Placeholders e Image Prioritizer.

No es obligatorio instalarlo ni recomendamos habilitar indiscriminadamente todas sus funciones en producción. Debe evaluarse según el proyecto.

Elementor y rendimiento: qué revisar

En páginas Elementor revisamos especialmente:

• Containers.
• DOM.
• Addons.
• Imágenes.
• Backgrounds.
• Animaciones.
• Sliders.
• Popups.
• Fuentes.
• Videos.
• Responsive.

Elementor incorpora actualmente optimizaciones de DOM dentro de Core y ofrece funciones específicas para priorización y lazy loading inteligente de imágenes. También dispone de Image Optimizer como producto adicional, por lo que no debe asumirse que cada herramienta está incluida automáticamente en cualquier instalación.

Mobile suele ser donde aparecen más problemas

Los celulares pueden tener:

• CPU más lenta.
• Conexiones más variables.
• Layout diferente.
• Más trabajo responsive.
• Mayor impacto de JavaScript.

Por eso no debemos optimizar únicamente desktop.

Search Console presenta Core Web Vitals separando móvil y ordenador.

Cómo utilizar PageSpeed Insights correctamente

1. Introduce una URL representativa.
2. Revisa primero los datos de usuarios reales.
3. Confirma si hay suficientes muestras.
4. Identifica LCP, INP y CLS.
5. Revisa móvil.
6. Revisa desktop.
7. Usa Lighthouse como diagnóstico.
8. Corrige.
9. Vuelve a probar.

Si no aparecen datos de campo, no significa que la página sea lenta. Puede significar simplemente que CrUX no dispone de una muestra suficiente para esa URL u origen.

Cómo utilizar Search Console para Core Web Vitals

El informe muestra datos reales por móvil y ordenador y agrupa URLs similares.

Esto es especialmente importante en WordPress.

Si 200 artículos comparten una misma plantilla y esa plantilla genera un problema de LCP, Search Console puede presentarlos como un grupo relacionado. No debemos obsesionarnos únicamente con la URL que Google utiliza como ejemplo.

Por qué PageSpeed cambia aunque no hayas cambiado la página

Una prueba de laboratorio puede variar por:

• Recursos disponibles.
• Condiciones de red.
• Carga del servidor.
• Scripts externos.
• Caché.
• Variabilidad propia del entorno de prueba.

Google reconoce expresamente que la puntuación puede variar entre ejecuciones aun sin cambios en la página.

Por eso conviene realizar varias mediciones y observar tendencias.

¿Necesitas llegar a 100 en PageSpeed?

No.

Una puntuación perfecta en Lighthouse no garantiza la mejor experiencia real ni primeras posiciones en Google.

El objetivo es conseguir:

• Buen rendimiento.
• Core Web Vitals saludables.
• Sitio funcional.
• Conversión.
• Accesibilidad.
• Estabilidad.

Nunca eliminaríamos Analytics, formularios, ecommerce o funciones esenciales únicamente para mostrar un “100” bonito en una captura.

Google señala además que no existe una única señal de experiencia de página que determine por sí sola el ranking.

Antes y después: cómo medir una optimización

Conserva los valores iniciales.

Antes

• PSI.
• CrUX.
• Search Console.
• LCP.
• INP.
• CLS.

Después

• Misma URL.
• Mismo tipo de dispositivo.
• Mismos indicadores.

No compares la home antigua con una landing distinta y presentes la diferencia como mejora técnica.

Necesitamos comparabilidad.

¿Cuánto tarda Google en reflejar una mejora?

Lighthouse puede mostrar cambios inmediatamente porque ejecuta una nueva prueba.

Los datos de CrUX y Search Console son otra historia: representan experiencias acumuladas de usuarios reales.

PSI utiliza actualmente una ventana móvil de 28 días, actualizada progresivamente. Esto no significa que “Google tarde exactamente 28 días”; las nuevas muestras comienzan a incorporarse conforme llegan.

Errores frecuentes al optimizar Core Web Vitals WordPress

• Perseguir PageSpeed 100.
• Optimizar solo la home.
• Mirar únicamente desktop.
• Ignorar datos reales.
• Confundir Lighthouse con CrUX.
• Seguir tutoriales que todavía utilizan FID.
• Aplicar lazy load al hero.
• Preload de demasiados recursos.
• Instalar varios plugins de caché.
• Combinar todos los CSS/JS sin analizar HTTP/2 o HTTP/3.
• Retrasar absolutamente todo JavaScript.
• Eliminar scripts comerciales necesarios.
• Instalar muchos addons Elementor.
• Subir imágenes enormes.
• No reservar dimensiones.
• Ignorar fuentes.
• Ignorar scripts externos.
• Culpar exclusivamente al hosting.
• Culpar exclusivamente a Elementor.
• Manipular la base de datos sin backup.
• Optimizar directamente producción.
• No volver a medir.

La constante detrás de casi todos estos errores es la misma: aplicar una receta sin haber diagnosticado la causa.

Checklist Core Web Vitals para WordPress

• PageSpeed Insights revisado.
• Datos de campo identificados.
• Lighthouse utilizado como diagnóstico.
• Search Console revisado.
• Mobile comprobado.
• Desktop comprobado.
• Elemento LCP identificado.
• Imagen LCP optimizada.
• Hero sin lazy load innecesario.
• INP revisado.
• JavaScript y terceros auditados.
• Plugins innecesarios eliminados.
• DOM revisado.
• CLS investigado.
• Imágenes con dimensiones.
• Fuentes revisadas.
• Caché configurada correctamente.
• Hosting revisado.
• PHP soportado y actualizado.
• CDN evaluado.
• Object cache evaluado.
• Backup realizado.
• Staging utilizado cuando corresponde.
• Resultados comparados después.

Prioridad de optimización: qué corregir primero

Una metodología práctica es:

Primero: la métrica deficiente.

Después: el problema que afecta muchas URLs, como un header o template global.

Luego: recursos visibles inicialmente y LCP.

Después: JavaScript y respuesta de interacción.

Luego: problemas de estabilidad CLS.

Finalmente: ajustes menores.

No deberíamos comenzar por una microoptimización simplemente porque sea fácil si existe un problema mucho mayor afectando a cientos de páginas.

Una página profesional debe ser rápida para usuarios reales, no solo para una herramienta

Una página profesional debería pensar en rendimiento desde el diseño, no después de terminarla.

Actualmente Codwelt publica planes de diseño de páginas web profesionales que, según el plan, incluyen WordPress + Elementor, diseño responsive, hosting avanzado, SSL, seguridad, optimización de rendimiento, Analytics, Search Console, SEO apoyado por IA, capacitación y soporte. El plan Full publica además una optimización de velocidad más intensiva orientada a móviles.

Eso no permite prometer PageSpeed 100 ni Core Web Vitals aprobadas para siempre. El rendimiento también cambia por contenido, plugins, usuarios reales, dispositivos, scripts externos y modificaciones posteriores.

La optimización debe considerarse desde el diseño, las imágenes, la infraestructura y la cantidad de recursos que utiliza la página, no únicamente después de que PageSpeed muestre una puntuación baja.

Preguntas frecuentes

Conclusión

Optimizar Core Web Vitals WordPress significa trabajar sobre nueve frentes principales:

1. Diagnóstico correcto.
2. Hosting y respuesta del servidor.
3. Caché.
4. Imágenes y recurso LCP.
5. Lazy loading.
6. JavaScript e INP.
7. DOM y Elementor.
8. Estabilidad y CLS.
9. Plugins y recursos externos.

La optimización efectiva empieza midiendo qué experimentan los usuarios reales y termina comprobando que los cambios mejoraron la métrica correcta sin romper funcionalidades importantes del sitio.

No necesitamos una puntuación perfecta para tener una buena página. Necesitamos una web rápida donde importa, estable, responsive, funcional y preparada para los usuarios reales que llegan desde celulares, buscadores, campañas y otros canales.

Fuentes

• Google web.dev — Web Vitals: métricas actuales y umbrales. Consultar Web Vitals
• Google web.dev — Umbrales de Core Web Vitals. Consultar definición de umbrales
• Google web.dev — INP reemplaza a FID. Consultar anuncio de INP
• Google for Developers — Información sobre PageSpeed Insights. Consultar PageSpeed Insights
• Google Search Central — Experiencia en las páginas. Consultar Page Experience
• Google Search Console — Informe Core Web Vitals. Consultar informe de Core Web Vitals
• web.dev — Optimize Largest Contentful Paint. Consultar optimización de LCP
• web.dev — Optimize Interaction to Next Paint. Consultar optimización de INP
• WordPress Developer Resources — Optimization. Consultar guía de rendimiento WordPress
• WordPress Developer Resources — Cache. Consultar documentación de caché WordPress
• WordPress Performance Team — Performance Lab. Consultar Performance Lab
• Elementor — Optimized DOM Output. Consultar optimización DOM de Elementor
• Elementor — Optimized Image Loading. Consultar carga optimizada de imágenes
• Codwelt — Diseño de páginas web profesionales. Consultar planes de páginas web Codwelt