Quitar JavaScript de WordPress: cómo diseñar el experimento antes de medir

Respuesta breve

Saber si quitar JavaScript sirve para acelerar WordPress exige comparar una plantilla con JavaScript mínimo frente a una con widgets globales, y esa comparación solo produce una conclusión defendible si el experimento se diseña antes de medir: hipótesis escrita, una única variable independiente, un candidato inmutable identificado por commit y hash, controles que no se mueven entre pasadas, y criterios de aceptación fijados de antemano. Sin ese armazón, cualquier diferencia de cifras se puede atribuir a la red, al host, a la versión del navegador o a la caché, y el resultado no sirve para decidir. Este es el protocolo del experimento; los números solo tienen valor cuando se ejecuta sobre un candidato fijo y se publican junto a sus limitaciones.

Puntos clave

• Una variable independiente por variante. Si cambian a la vez el JavaScript y las imágenes, el resultado no atribuye nada.
• El candidato se fija con commit, ZIP y hashes; si cambian los bytes, las pruebas afectadas se repiten.
• Se registran mediana y peor valor de varias pasadas, no la mejor cifra obtenida.
• Los datos de laboratorio no son datos de campo y no se presentan como tales.
• Los umbrales vigentes de Core Web Vitals —LCP 2,5 s, INP 200 ms, CLS 0,1 en el percentil 75— son referencia de campo, no la puntuación de una herramienta.
• La prueba incluye interacción real con teclado y puntero: una optimización que rompe el uso es una regresión, no una mejora.
• Una ejecución fallida permanece en la serie con su explicación; repetir hasta obtener una cifra favorable invalida el protocolo.

El experimento se diseña antes de medir

1. Hipótesis escritaQué se espera y por qué.
2. Una variableJavaScript o imágenes; nunca las dos a la vez.
3. Candidato fijadoCommit, ZIP y hashes; si cambian los bytes, se repite.
4. ControlesContenido inmutable e interacción real con teclado.
5. Mediana y peor valorDe varias pasadas, no la mejor cifra.
6. Laboratorio ≠ campoLos umbrales se acreditan con visitas reales.

Hipótesis

Al limitar JavaScript inicial a navegación y mejoras progresivas, la carga tendrá menos bytes y tareas que una implementación con widgets globales, que es justo la comparación que ordena Elementor frente a desarrollo a medida. Esto puede favorecer interacción y estabilidad, pero servidor, imágenes, fuentes y red siguen influyendo.

La hipótesis se formula con reservas explícitas porque el JavaScript es una de varias causas del trabajo del navegador y rara vez la dominante. Una plantilla con poco script pero con una imagen de cabecera sin dimensionar y tres fuentes bloqueantes puede rendir peor que otra con más script y esos frentes resueltos. Declararlo evita que el experimento se convierta en una demostración de la conclusión que ya se quería.

Lo que sí predice con precisión es dónde debería verse el efecto: bytes de JavaScript transferidos, número y duración de tareas largas del hilo principal, y respuesta a la primera interacción. Si la variante reduce bytes pero no mueve las tareas largas, la hipótesis queda parcialmente refutada y el hallazgo —que el peso no era el cuello de botella— vale tanto como una confirmación.

Variables

• independiente: bundle y patrón de carga;
• dependientes: bytes, requests, tareas largas, LCP, INP simulado, CLS y errores;
• controladas: contenido, servidor, imagen, viewport, throttling, navegador y caché;
• externas: carga del host y variación de herramienta.

Las variables externas no se eliminan: se acotan y se declaran. La carga del host varía a lo largo del día, y una misma plantilla medida por la mañana y por la tarde puede dar resultados distintos sin que el código haya cambiado. La mitigación es intercalar las pasadas —control, variante, control, variante— en lugar de agrupar primero todas las del control, para que la deriva del entorno afecte por igual a ambas ramas.

La versión del navegador y la de la herramienta también son variables externas y se anotan en el registro: un cambio de versión entre pasadas invalida la comparación aunque el código sea idéntico. El protocolo congela el entorno de medición durante toda la serie.

Plantillas

Inicio, landing local, servicio, artículo, herramienta y contacto. Cada una se prueba en móvil y escritorio, con JavaScript activo y desactivado cuando la tarea lo permite.

Se eligen seis plantillas y no una porque el efecto del JavaScript no es homogéneo. Una portada con carrusel, contadores y mapa carga un perfil de script muy distinto al de un artículo estático, y la herramienta interactiva es el caso donde el script es funcionalidad, no adorno. Medir solo la portada produciría una conclusión intrasladable al resto del sitio; medir solo el artículo, la contraria.

La prueba con JavaScript desactivado no simula a un usuario real: delimita qué parte del contenido y de la navegación existe sin ejecución. Es un control de degradación —si el menú no abre o el contenido principal desaparece, hay una dependencia que conviene conocer antes de decidir cómo se carga—.

Medir solo la portada produciría una conclusión intrasladable al resto del sitio; medir solo el artículo, la contraria.

Procedimiento

1. fijar commit, ZIP y hashes;
2. restaurar datos de fixture;
3. ejecutar tres pasadas frías y calientes;
4. guardar JSON, trazas y capturas;
5. registrar mediana y peor valor;
6. repetir tras cualquier corrección que cambie bytes;
7. revisar teclado y accesibilidad para evitar una optimización regresiva.

La separación entre pasada fría y caliente es la que más resultados contamina cuando se omite. Una medición con caché de página llena, opcode caché templada y recursos ya en el navegador describe una situación real —la del visitante recurrente en una página popular— pero distinta de la del primer acceso. Mezclar ambas en una misma media produce una cifra que no corresponde a ningún usuario. El registro separa las dos series y las compara por separado; la metodología de benchmark de caché fría y caliente desarrolla ese procedimiento.

Tres pasadas es un mínimo para hablar de mediana, no un número mágico. La señal de que hacen falta más es la dispersión: si el peor valor y la mediana difieren mucho, el entorno no está lo bastante controlado y añadir pasadas sin corregirlo solo suaviza el problema. Registrar el peor valor junto a la mediana mantiene visible esa dispersión.

Diseñar controles

El control conserva contenido, servidor, caché, viewport y conjunto de interacciones. La variante cambia una sola decisión de JavaScript: por ejemplo, retirar una dependencia o cargar un módulo únicamente donde se usa. Si también cambian imágenes o CSS, se crea otra variante y no se mezclan resultados.

Las pruebas incluyen una interacción real, no solo carga inicial. Menú, formulario y herramientas deben responder con teclado y puntero. Cada artefacto referencia el commit o hash del paquete. Si una ejecución falla, permanece en la serie con su explicación; repetir hasta obtener una cifra favorable invalidaría el protocolo.

El contenido de fixture cumple una función que va más allá de la comodidad: garantiza que el número de elementos, el peso de las imágenes y la longitud del texto son idénticos entre pasadas. Un experimento sobre contenido real que alguien edita a mitad de la serie mide dos cosas a la vez. El fixture se restaura desde un volcado versionado antes de cada rama.

Qué se mide y qué no

La distinción entre laboratorio y campo condiciona toda la lectura. Una herramienta de laboratorio ejecuta la página en condiciones simuladas y devuelve métricas reproducibles y comparables entre sí; los datos de campo proceden de visitas reales, con sus dispositivos, redes y patrones de interacción. El experimento produce laboratorio, y por tanto puede decir «esta variante hace menos trabajo en el hilo principal», pero no puede decir «esta variante mejora la experiencia de los usuarios» sin una lectura de campo posterior.

INP es el caso más claro de esa frontera. Es una métrica de interacción real: mide la latencia de las interacciones que ocurren durante la visita, y en laboratorio solo puede aproximarse con un guion de interacciones definido de antemano. El valor simulado sirve para comparar dos variantes sometidas al mismo guion, no para afirmar que se cumple el umbral. Los umbrales de Core Web Vitals —LCP por debajo de 2,5 s, INP por debajo de 200 ms y CLS por debajo de 0,1, evaluados en el percentil 75 de las visitas— pertenecen al campo, y así se citan en el informe.

Qué acredita cada métrica en laboratorio y qué no acredita.

Métrica	Qué acredita en laboratorio	Qué no acredita
Bytes y peticiones	diferencia real de carga transferida	que esa diferencia se note en el uso
Tareas largas	trabajo del hilo principal comparable	latencia percibida por un usuario
LCP	orden de pintado bajo condiciones fijas	el LCP de campo del sitio
INP simulado	respuesta al guion de interacciones definido	cumplimiento del umbral de 200 ms
CLS	estabilidad del layout en la carga probada	desplazamientos causados por interacción real

Criterios

El experimento no declarará éxito por una puntuación. Comparará presupuestos del proyecto y explicará limitaciones. Los datos locales no se presentarán como campo. La guía de Core Web Vitals desarrolla la metodología.

Un presupuesto es un límite acordado antes de medir: por ejemplo, un tope de bytes de JavaScript por plantilla o un máximo de tareas largas en la carga inicial. Comparar contra el presupuesto convierte el resultado en una decisión —dentro o fuera— en lugar de en una discusión sobre si la mejora es suficiente. La puntuación agregada de una herramienta no sirve para eso: mezcla métricas con pesos propios y puede subir mientras empeora lo que importa al proyecto.

El criterio de aceptación incluye una condición de no regresión funcional: una variante que reduce bytes pero rompe la navegación por teclado, deja errores en consola o impide enviar un formulario no se acepta aunque gane en todas las métricas. Esa comprobación se ejecuta sobre las mismas plantillas y el mismo candidato.

En cuatro láminas

1 variable por variante. Si cambian a la vez el JavaScript y las imágenes, el resultado no atribuye nada.

ficha: commit: a1b2c3d / paquete: tema-v1.4.zip / sha256: 9f3a…e2c1 / fixture: volcado del 2026-09-01 / plantillas: 6 · pasadas: 5 / registro: mediana y peor valor / / # si cambian los bytes, se repite

Qué acredita cada uno. Columnas: Laboratorio, Campo. LCP: Laboratorio → Localiza el recurso lento; Campo → Acredita el umbral. INP: Laboratorio → Encuentra las tareas largas; Campo → El único INP real. CLS: Laboratorio → Reproduce el salto; Campo → Lo confirma en móvil real

Errores frecuentes

• Cambiar dos cosas en la variante. Tocar el JavaScript y las imágenes a la vez impide atribuir el resultado a ninguna de las dos.
• Medir sobre contenido vivo. Si alguien edita una página a mitad de la serie, las dos ramas dejan de ser comparables.
• Quedarse con la mejor pasada. La mediana y el peor valor describen el comportamiento; la mejor cifra describe la suerte.
• Presentar laboratorio como campo. Un INP simulado no acredita el cumplimiento del umbral de 200 ms.
• Perseguir la puntuación agregada. Puede subir mientras empeora la métrica que afecta al usuario.
• Ignorar la accesibilidad en la variante. Retirar script que sostiene el foco o el menú es una regresión disfrazada de optimización.
• Descartar las ejecuciones fallidas. Eliminar del registro lo que no encaja convierte el experimento en una ilustración.

Preguntas habituales

¿Por qué una sola variable por variante?

Porque con dos, el resultado no es atribuible. Si una variante quita JavaScript y además cambia las imágenes, la diferencia medida puede venir de cualquiera de las dos, y no hay forma de saber cuál. Es la restricción que convierte una comparación en un experimento.

¿Puedo quedarme con la mejor pasada?

No: describe lo que pasó una vez, no el comportamiento. Lo que se registra es la mediana y el peor valor de la serie, que es lo que un visitante puede encontrarse. Quedarse con la mejor cifra obtenida convierte la medición en una selección, y una selección no se puede repetir.

¿Vale una medición de laboratorio para acreditar Core Web Vitals?

No. Los umbrales se evalúan sobre visitas reales en el percentil 75; el laboratorio sirve para encontrar la causa, no para acreditar el cumplimiento. Presentar un INP simulado como si fuera el del sitio es la confusión más extendida, y además no la señala ninguna herramienta.

¿Qué hago con una ejecución que salió rara?

Se queda en la serie, con su explicación. Eliminar del registro lo que no encaja convierte el experimento en una demostración de lo que ya se quería demostrar. Las pasadas anómalas suelen indicar una variable no controlada —una caché fría, un vecino ruidoso— que conviene identificar, no borrar.

Próximo paso

Antes de ejecutar nada, escribe el presupuesto por plantilla y el criterio de aceptación, y congela el candidato con su commit y sus hashes. Después define el guion de interacciones que se repetirá idéntico en ambas ramas, porque es lo que hace comparables las medidas de respuesta. Ejecuta las pasadas intercaladas, guarda todos los artefactos —incluidos los de las ejecuciones fallidas— y redacta el resultado indicando qué se midió en laboratorio y qué haría falta observar en campo para confirmarlo. Publicar también lo que salió mal es lo que separa un experimento de una demostración, el mismo criterio que sostiene auditar la propia web con método, evidencia y límites. Si el objetivo es reducir la latencia de interacción en un sitio ya en producción, el trabajo previo está descrito en cómo mejorar INP en WordPress.

Fuentes

• web.dev, Core Web Vitals: umbrales y percentil 75 — documentación oficial.
• web.dev, Interaction to Next Paint — documentación oficial.
• Chrome for Developers, informe de experiencia de usuario (CrUX) — documentación oficial.

Servicio relacionado

Si esto es lo que te está pasando, auditoría seo es el trabajo que lo resuelve. Diagnóstico primero, prioridades después.

Ver auditoría seo