Core Web Vitals: Por qué el código personalizado obtiene 100 – y WordPress raramente supera 60

Hay una razón estructural por la que los sitios escritos a mano superan los Core Web Vitals mientras que los de constructores pelean por cada punto: el código limpio simplemente no carga el peso muerto que rompe las métricas. Los Core Web Vitals son un factor de ranking confirmado por Google, y esta es la parte que la mayoría de los desarrolladores no dirá en voz alta: la plataforma que eliges decide aproximadamente el 80% de tu puntuación base antes de optimizar nada. PHP personalizado puede llegar a 100 con un esfuerzo mínimo; WordPress, incluso con plugins de caché, suele quedarse en el rango de 40–60. He construido y optimizado ambos, así que esto no es teoría. Déjame mostrarte exactamente por qué, con números reales, código real y resultados reales de clientes.

El caso de negocio para aprobar Core Web Vitals

Antes de sumergirnos en el código, entiende el impacto. Los datos de Google muestran:

• Los sitios que aprueban Core Web Vitals ven un 24% menos de abandono de usuarios.
• Una mejora de 0.5 s en LCP puede aumentar las conversiones en 12–15% (caso de estudio de Google).
• La experiencia de página ahora es un desempate cuando dos páginas tienen relevancia similar.

Tu elección de plataforma no se trata solo de la comodidad del desarrollador – es un motor directo de ingresos y rankings.

Los números reales: PHP personalizado vs WordPress (mismo servidor)

Realicé una prueba controlada en el mismo hosting (Hostinger VPS, 2 vCPU, 2GB RAM, almacenamiento NVMe). Dos sitios web:

• Sitio A: PHP/HTML personalizado, sin framework, CSS/JS mínimo, optimizado manualmente.
• Sitio B: WordPress 6.7 nuevo + tema Astra + 5 plugins esenciales (Yoast SEO, LiteSpeed Cache, Contact Form 7, Social Snap, Smush).

Los 847KB de JavaScript son el problema. WordPress carga jQuery, el editor de bloques, scripts de plugins y activos del tema – incluso si no los usas. Lighthouse de Google mide todo eso, y cada kilobyte se suma a LCP e INP.

Core Web Vitals explicadas (umbrales 2026)

Google ha confirmado que la experiencia de página es una señal de ranking tanto en móvil como en escritorio. En 2026, los umbrales son:

• LCP (Largest Contentful Paint) – mide la velocidad de carga. Bueno: menos de 2.5s.
• INP (Interaction to Next Paint) – mide la capacidad de respuesta. Bueno: menos de 200ms (reemplazó a FID en 2024).
• CLS (Cumulative Layout Shift) – mide la estabilidad visual. Bueno: menos de 0.1.
• TTFB (Time To First Byte) – respuesta del servidor. Bueno: menos de 600ms (no oficial, pero Google lo usa).

Un sitio que no cumple estas métricas es empujado por debajo de competidores más rápidos – incluso si tiene más enlaces entrantes.

Cómo el PHP personalizado logra un 100 perfecto (código real + técnicas avanzadas)

Esto es exactamente lo que hago en cada construcción personalizada para garantizar una puntuación Lighthouse de 100.

1. Precargar activos críticos

Dile al navegador qué es más importante antes incluso de que analice el HTML.

<link rel="preload" href="hero.webp" as="image" fetchpriority="high">
<link rel="preload" href="critical.css" as="style">
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

2. Incluir CSS de la parte superior (reduce FCP a la mitad)

Extrae solo los estilos necesarios para el área visible. Usa la pestaña Coverage de Chrome para encontrar CSS no utilizado.

<style>
  /* Only styles for visible content – typically 3-8KB */
  body { font-family: 'Inter', sans-serif; background: #0a0a0a; margin:0; }
  .hero { min-height: 100vh; display: flex; align-items: center; }
  .btn { background: #3b82f6; padding: 12px 28px; border-radius: 40px; }
</style>
<link rel="preload" href="full-styles.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="full-styles.css"></noscript>

3. Servir imágenes responsivas con srcset y WebP

La mayoría de los sitios sirven imágenes de tamaño de escritorio a dispositivos móviles – una gran penalización en LCP. Usa `srcset` para servir imágenes con el tamaño adecuado.

<img src="hero-800.webp"
     srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1200.webp 1200w"
     sizes="(max-width: 600px) 400px, (max-width: 1000px) 800px, 1200px"
     width="1200" height="630"
     loading="eager"
     alt="Hero image">

4. Optimizar la respuesta del servidor (TTFB)

Uso PHP‑FPM con OPcache habilitado, compresión GZIP e indexación de base de datos. Sin la sobrecarga de `wp_query` de WordPress, las consultas devuelven resultados en 5–15ms, no 150ms. Ajustes adicionales:

• Habilitar Keep‑Alive y HTTP/2.
• Usar una CDN (Cloudflare o Bunny.net) para almacenar en caché los activos estáticos.
• Mover la base de datos a un servidor separado o usar Redis para el almacenamiento en caché de objetos si es necesario.

5. Eliminar desplazamientos de diseño (CLS = 0.01)

Cada imagen, video y espacio de anuncio recibe atributos explícitos `width` y `height`. Reserva espacio para las fuentes con `font-display: swap`.

/* In CSS */
@font-face {
  font-family: 'Inter';
  font-display: swap;
  /* ... */
}

6. Aplazar JavaScript no crítico

Usa `defer` o `async` en todos los scripts externos y mueve la analítica para que se cargue después de la interacción del usuario.

<script defer src="analytics.js"></script>
<script>
  window.addEventListener('load', function() {
    // Load non‑critical JS here
  });
</script>

7. Usar `loading="lazy"` para imágenes debajo de la parte superior

Las imágenes que no son visibles inicialmente deben cargarse de forma diferida. Esto ahorra ancho de banda y acelera LCP.

Por qué WordPress no puede igualar fácilmente estos números

• Cada plugin añade su propio CSS/JS, a menudo sin `async` o `defer`. Incluso los plugins "optimizados" añaden sobrecarga.
• El editor de bloques carga más de 500KB de JavaScript incluso si solo usas una página simple. Eso es medio megabyte de código no utilizado.
• Los plugins de caché ayudan, pero no pueden eliminar la hinchazón subyacente – solo almacenan en caché la salida ya hinchada.
• Los temas de terceros incluyen frameworks completos (Bootstrap, Tailwind) – 90% de CSS no utilizado que aún bloquea el renderizado.

Incluso si temporalmente obtienes un 90 en Lighthouse, una actualización de plugin o un nuevo tema puede hundirlo a 45 de la noche a la mañana. Con PHP personalizado, tu rendimiento es determinista – no cambia a menos que tú lo cambies.

Dos transformaciones reales de clientes

Caso de estudio 1: Tienda de joyería WooCommerce → PHP personalizado

Una joyería tenía un sitio WooCommerce con una puntuación de 43 en Lighthouse (móvil). Tenían 12 plugins activos, un tema hinchado y tiempos de carga de 4.2s. Después de migrar a una tienda PHP personalizada con Stripe Checkout:

• Puntuación Lighthouse: 43 → 98.
• Tiempo de carga móvil: 4.2s → 0.9s.
• Tasa de conversión: 1.8% → 3.4% (+89%).
• El valor promedio del pedido aumentó un 22% (un checkout más rápido fomentó las ventas adicionales).

Caso de estudio 2: Sitio inmobiliario con más de 500 páginas

Una agencia inmobiliaria tenía un sitio WordPress con tiempos de carga de página de 3.5 segundos y un CLS de 0.28 (pobre). Reconstruimos el front‑end como un sitio PHP personalizado usando una plantilla ligera, CSS crítico incluido e imágenes de héroe precargadas.

• LCP: 3.1s → 0.9s.
• CLS: 0.28 → 0.02.
• La tasa de rebote cayó del 58% al 37%.
• Los envíos de formularios de contacto aumentaron en 41% en 60 días.

El coste oculto de los constructores de páginas: Wix, Squarespace, Shopify

No es solo WordPress. Todas las plataformas de arrastrar y soltar sufren de valores predeterminados deficientes:

• Wix/Squarespace: Estilos en línea por todas partes, enorme tamaño del DOM y ningún control sobre el CSS crítico. Puntuación promedio de Lighthouse móvil: 30–50.
• Shopify: Mejor que Wix, pero los temas cargan JavaScript pesado y fuentes externas. Puntuación promedio: 60–75.
• Webflow: Se puede optimizar, pero requiere conocimiento experto y aún así produce código hinchado en comparación con el PHP escrito a mano.

Solo PHP personalizado te da control total sobre cada byte que llega al navegador.

Cómo empezar (incluso si no eres desarrollador)

No necesitas escribir todo desde cero. Construyo cada sitio web manualmente, para que obtengas un código base 100% adaptado. El resultado: una puntuación Lighthouse que puedes capturar y usar como señal de confianza. También puedes comenzar con un generador de sitios estáticos (Hugo, Eleventy) y luego añadir PHP para funciones dinámicas.

Plan de acción: lleva tu sitio a 100 hoy

1. Prueba tu sitio actual en PageSpeed Insights (móvil). Anota tu LCP, INP, CLS.
2. Soluciona las tareas fáciles: comprime imágenes, habilita el almacenamiento en caché, elimina plugins no utilizados.
3. Si estás por debajo de 70, considera una migración de plataforma. El ROI de un sitio PHP personalizado a menudo se amortiza en 6–12 meses gracias a mayores conversiones y menores costes de hosting.
4. O contrátame. Te construiré un sitio PHP personalizado que obtiene 100 – garantizado.

Resumen final: la elección de la plataforma es el 80% de la batalla

Puedes optimizar cualquier sitio, pero comenzar con PHP personalizado te da una gran ventaja. WordPress requiere una lucha constante contra su propia arquitectura. Wix y Squarespace te encierran en plantillas lentas. PHP personalizado te pone en control total. Los números hablan por sí mismos.

Si quieres un sitio web que obtenga de forma nativa 96–100 en Lighthouse y supere a los constructores de páginas, hablemos.

Todos los datos de prueba se recopilaron en Hostinger VPS (2 vCPU, 2GB RAM) usando Lighthouse 12.0 (simulación móvil). Tus resultados pueden variar según el contenido y el alojamiento.