La optimización está terminada y llega el informe. Hay capturas verdes, varias gráficas y una frase estupenda: «la web ya va mucho mejor». Falta una pieza pequeña, pero bastante útil: saber qué puedes dar por comprobado.
Un informe de optimización WordPress debería permitir revisar el trabajo sin tener que reconstruirlo a base de correos. Qué cambió, qué se midió, con qué condiciones, qué funciones siguen operativas y qué queda pendiente. Esa es la base para aceptar una entrega con criterio.
Aquí tienes una plantilla original, una matriz de revisión y un ejemplo de cálculo con datos ficticios. Sirven para leer y pedir evidencias; no describen una optimización realizada para un cliente. Si necesitas revisar una entrega, puedes solicitar una evaluación de resultados de rendimiento WordPress indicando alcance, URLs y problema.
El informe debe responder al encargo aprobado
Antes de leer las cifras, recupera la propuesta aceptada. Identifica las páginas, perfiles y funciones incluidos. Una mejora en la portada puede ser relevante, pero no responde por sí sola a un encargo sobre filtros de producto o cálculo de envío.
Relaciona cada requisito con una evidencia. Si el alcance incluía una interacción, pide el registro de esa interacción. Si incluía conservar el diseño, pide la revisión de los elementos acordados. La comprobación debe seguir la promesa concreta que se aprobó.
La guía de presupuesto de optimización WordPress para 2027 ayuda a definir esa relación antes de contratar. Este informe se sitúa al final: organiza la evidencia que se entrega y las decisiones que permite tomar.
Plantilla copiable para una entrega revisable
Usa una ficha por intervención y enlaza los informes detallados desde ella. La ficha es un índice de decisiones, no un lugar para pegar contraseñas, datos de clientes o trazas completas de sesiones privadas.
Informe de optimización WordPress | referencia:
Alcance aprobado y responsable de aceptación:
URL, plantilla, idioma y acción revisados:
Versión anterior / versión entregada / fecha de cambio:
Cambios aplicados y dependencia de cada uno:
Método, herramienta y condiciones de medición:
Muestras originales y resumen utilizado:
Resultado de rendimiento por requisito:
Resultado funcional y visual por recorrido:
Comprobación tras publicación y alternativa segura:
Limitaciones, excepciones y tareas pendientes:
Decisión, evidencia citada, responsable y fecha:Asigna referencias a los archivos y resultados para poder localizarlos después. «Captura final» dice poco cuando hay seis versiones adjuntas. Un nombre de informe, fecha y URL permiten encontrar la evidencia concreta que respaldó la decisión.
Si una casilla no tiene resultado, conserva «no medido» o «pendiente» con su motivo. Completarla con una suposición hace más difícil el siguiente diagnóstico. Un informe útil distingue lo conocido de lo que todavía necesita trabajo.
Comprueba la comparabilidad antes de calcular la mejora
Revisa URL, herramienta, perfil, red, estado de sesión, consentimiento y criterio de caché. La versión desplegada debe estar identificada. Cuando una condición cambia, el informe debe explicar si la comparación sigue respondiendo a la misma pregunta.
La guía de pruebas reproducibles de WordPress desarrolla cómo preparar ese ensayo. Al revisar una entrega, pide el protocolo aplicado y las diferencias documentadas. No necesitas volver a definir cada herramienta para comprobar si se respetaron las condiciones acordadas.
Una comparación entre dos estados distintos puede ser útil para diagnosticar. El problema aparece cuando se presenta como un antes y después de la intervención sin justificarlo. Un dispositivo diferente o una sesión distinta pueden cambiar la lectura de las cifras.
Matriz de revisión de la entrega
Esta matriz es una herramienta editorial propia. En cada fila registra resultado, referencia y responsable. Los estados posibles pueden ser «verificado», «fallido», «incompleto» o «no aplicable con motivo»; define su uso con el equipo que aprueba.
| Referencia | Pregunta de revisión | Evidencia que debe localizarse |
|---|---|---|
| VAL-01 | ¿Se midió el alcance acordado? | URLs, acciones, perfiles y versión |
| VAL-02 | ¿La comparación usa condiciones coherentes? | Protocolo, muestras y diferencias |
| VAL-03 | ¿Mejoró el indicador pertinente? | Resultado por requisito y sus límites |
| VAL-04 | ¿Funcionan los recorridos afectados? | Pruebas funcionales y resultados |
| VAL-05 | ¿Se conserva lo acordado de diseño y consentimiento? | Revisión de estados y elementos incluidos |
| VAL-06 | ¿Se verificó la versión publicada? | Despliegue, revisión y pendientes asignados |
No conviertas la tabla en seis marcas verdes sin archivos detrás. Si el proveedor entrega una captura de laboratorio, registra qué requisito acredita. El mismo documento puede servir para varias filas, pero solo cuando su alcance cubra realmente esas preguntas.
La aceptación necesita mirar también lo que falla. Una función comercial rota requiere una decisión explícita y su corrección o alternativa acordada. El promedio del resto de la tabla no transforma ese fallo en una entrega completa.
Tres ejemplos de decisión escrita
Los siguientes casos son ficticios y muestran cómo registrar el resultado de una revisión. No representan trabajos realizados ni aprobaciones de clientes.
- REV-01: comprobación acotada cerrada. El informe contiene muestras comparables y pruebas de las funciones incluidas. El responsable acepta esos requisitos identificados; el seguimiento posterior de usuarios permanece abierto con fecha y propietario. La nota cita los archivos revisados y deja fuera los escenarios no probados. Así se sabe qué se ha aceptado sin ampliar la conclusión a toda la web.
- REV-02: función que falla. Una métrica de carga mejora en el ejemplo, pero el formulario del recorrido acordado no completa su operación. Se registra el fallo, la evidencia y el responsable de corregirlo. La decisión sobre corregir o volver a un estado seguro corresponde al procedimiento de cambio. No se da por completa esa parte del encargo por el resultado de la métrica.
- REV-03: falta evidencia localizable. La presentación contiene cifras, pero no permite localizar condiciones ni muestras. Se solicita la documentación necesaria para valorar la comparación. El estado permanece incompleto: eso identifica una carencia del informe, sin concluir todavía que la intervención técnica no funcionó ni contratar otra optimización a ciegas.
En los tres casos queda escrita la siguiente acción y quién la asume. Ese registro reduce las conversaciones circulares: el proveedor sabe qué entregar y quien aprueba sabe qué deberá revisar para cambiar el estado.
Ejercicio original: la cuenta sale bien y la conclusión no
Estos datos son ficticios. El 25 de octubre de 2026 ejecutamos un cálculo local con dos series inventadas de cinco tiempos. Las etiquetamos deliberadamente con perfiles diferentes para comprobar qué permite concluir su resumen. No proceden de pruebas de una web ni de una intervención de cliente.
Serie A, perfil móvil: 3200, 2800, 3000, 3100, 2900 ms
Serie B, perfil escritorio: 2600, 2400, 2500, 2700, 2300 ms
Medianas calculadas: 3000 ms y 2500 ms
Diferencia aritmética: 500 ms menos; 16,67 %
Perfiles coincidentes: noEl cálculo de las medianas y la diferencia es correcto para esas series. No demuestra una mejora de rendimiento causada por una optimización: hemos cambiado el perfil de comparación. La decisión de revisión sería pedir evidencia comparable antes de aceptar esa afirmación.
El ejemplo separa dos comprobaciones del informe: exactitud del resumen y validez de la comparación. Una hoja de cálculo puede resolver la primera sin resolver la segunda. Ninguno de estos números es un resultado real que debas exigir a tu proyecto.
Un caso observado que tampoco es un antes y después
En la guía sobre PageSpeed aprobado y recorridos lentos documentamos perfiles de laboratorio de esta web: escritorio 99 y móvil emulado 79. No hubo una optimización entre ambos, y no había datos de usuarios reales disponibles.
Si esas dos capturas llegaran sin contexto a un informe, sería fácil confundirlas con una evolución. La pregunta de revisión es qué cambió entre ellas. El enlace al informe, el perfil y la fecha permiten comprobar que responden a condiciones distintas.
El trabajo de aceptar una entrega consiste precisamente en conservar ese contexto. Una cifra puede ser auténtica y estar utilizada para una conclusión que no acredita. Pide que cada resultado se relacione con su prueba y con el requisito que pretende cerrar.
Un resumen visual debe permitir llegar al detalle
La referencia sirve para pensar en la jerarquía de un informe: resumen, comparación y detalle localizable. Sus indicadores pertenecen al proyecto mostrado. En tu entrega, cada tarjeta necesita identificar qué mide y enlazar la evidencia que permite revisarla.
Separa resultados de carga, interacción y función
Una medición de carga inicial no acredita automáticamente la respuesta de filtros, menús o formularios. Organiza el informe según el momento observado. Así puedes ver si el problema del encargo recibió una comprobación específica.
La guía de web.dev sobre medición distingue laboratorio y campo. En la entrega, identifica el origen de cada resultado y conserva su alcance. Los datos históricos de usuarios y una prueba controlada no deben tratarse como la misma muestra.
Además, comprueba que el recorrido termine correctamente. Un formulario puede responder pronto y no completar la operación esperada. El informe necesita el resultado funcional acordado, junto al tiempo observado cuando ese tiempo forme parte del objetivo.
Diseño y consentimiento también forman parte de la revisión
Identifica qué se debía preservar: imágenes, tipografía, navegación, movimiento o estados del banner, según el encargo. Pide una revisión de las vistas relevantes y de los cambios aprobados. No presupongas que un recurso eliminado era prescindible.
Si la intervención modifica carga diferida o scripts, registra qué estados de consentimiento se comprobaron y qué funciones se observaron en ellos. Una prueba sin elección de cookies no acredita automáticamente el comportamiento posterior a otra elección.
Cuando una comprobación no pudo realizarse, deja el estado incompleto con su dependencia. Esa información permite programar la revisión pendiente sin presentar como verificado un escenario que nadie recorrió.
Qué debe quedar documentado al publicar
El informe debe identificar la versión puesta en producción, fecha y cambios aplicados. Conserva qué diferencias existían respecto al entorno de ensayo y qué se revisó después del despliegue. Aprobar una copia de pruebas no equivale a observar la versión publicada.
Añade configuración y dependencias que necesitará mantener otro profesional, con sus ubicaciones protegidas. Registra licencias, reglas relevantes y responsables; los valores secretos pertenecen a su sistema de gestión, no al PDF comercial.
Si después de una actualización reaparece una lentitud, la guía de comparación tras cambios de WordPress ayuda a investigar desde una versión conocida. Un buen informe de entrega deja esa referencia disponible.
Cómo registrar la decisión y los pendientes
Escribe qué alcance se acepta, con qué evidencias y en qué fecha. Una aceptación parcial debe nombrar las filas pendientes y su efecto sobre la entrega. Cada tarea necesita responsable, siguiente comprobación y criterio de cierre.
Separa defectos observados, funciones adicionales solicitadas y seguimiento de datos que requiere tiempo. Son conversaciones distintas. El informe debe permitir decidirlas sin borrar el resultado original ni atribuir a la intervención cualquier cambio posterior.
Si el trabajo incluye observar datos de usuarios después del lanzamiento, conserva ese compromiso con su método y plazo. Una comprobación de laboratorio puede cerrarse mientras ese seguimiento continúa abierto, siempre que el documento lo indique con claridad.
Un antes y después real de esta web: cómo se entrega la fuente
El 25 de octubre de 2026 cambiamos la entrega de Sora en nuestra propia web. Antes, la portada española pedía una hoja de estilos de Google Fonts y después el archivo tipográfico. Ahora utiliza los mismos archivos originales desde el dominio de WebSpeed Optimize y las declaraciones de fuente van incluidas en el HTML. Conservamos la tipografía, sus pesos, los subconjuntos de caracteres y la licencia SIL Open Font License de los autores de Sora.
La intervención eliminó una dependencia externa de estilos; no fue un rediseño ni un cambio de contenido. Los archivos del tema conservaron sus huellas y las nueve páginas y entradas comprobadas mantuvieron sus datos durante la intervención. También contrastamos el texto principal y la familia, peso, tamaño y dimensiones del título en las doce cargas: coincidían.
El protocolo que usamos para comparar
Medimos seis cargas antes y seis después de la misma portada pública en español, con Chromium 152.0.7977.82. Cada visita abrió un navegador nuevo, ventana de 1280 × 900 píxeles, escala 1 y configuración regional es-ES. Desactivamos la caché del navegador y fijamos una emulación de red de 150 ms de latencia, 200.000 bytes por segundo de descarga y 93.750 de subida, con ralentización de CPU por cuatro.
No hubo interacción ni elección de cookies durante la muestra: todas las visitas empezaron con un contexto anónimo nuevo. Registramos el candidato LCP, FCP y desplazamientos de diseño en una ventana inicial de aproximadamente ocho segundos. Es una medición de escritorio con emulación; no representa un teléfono físico ni datos de usuarios reales. Tampoco garantiza una caché fría de DNS, sistema operativo o CDN.
| Indicador | Antes | Después |
|---|---|---|
| Cargas | 6 | 6 |
| Candidato LCP, mediana | 2396 ms | 2316 ms |
| Candidato LCP, mínimo–máximo | 2300–2512 ms | 2224–2608 ms |
| CLS de la ventana, mediana | 0,0264 | 0,0264 |
| Peticiones para la fuente observadas por visita | 2 externas: CSS y WOFF2 | 1 local: WOFF2 |
La conclusión cabe en algo más que un número verde
La mediana del candidato LCP bajó 80 ms, pero los rangos se solapan. La carga posterior más lenta también fue más lenta que cualquiera de las anteriores. Hemos conservado ese resultado, no lo hemos mandado a tomar café fuera de la tabla. Las dos series se ejecutaron de forma consecutiva; la variación de red y servidor sigue siendo una posible influencia.
Lo que sí queda comprobado es el cambio de entrega: en las seis visitas anteriores aparecieron las dos peticiones externas para la fuente; en las seis posteriores, una petición al archivo local. El navegador siguió renderizando Sora y el título mantuvo sus dimensiones. Conservamos la entrega local por esa reducción de dependencias y por la ausencia de una regresión de diseño observada, sin convertir 80 ms de esta muestra en una promesa universal.
Descarga las doce mediciones, el CSV y el contexto de las respuestas. El paquete incluye todos los intentos de la serie, las condiciones y sus fechas. La guía de web.dev sobre fuentes también recomienda comprobar la entrega en lugar de dar por hecho que servirlas localmente siempre será más rápido.
Este caso no acredita INP de campo, una puntuación Lighthouse, más ventas ni una subida de clics en Google. Para revisar una entrega, pide este mismo conjunto: cambio identificable, condiciones comparables, serie completa, comprobaciones de diseño y una conclusión proporcional a lo medido. El informe tiene que ayudarte a aceptar el trabajo y decidir qué merece investigarse después.
Qué enviar para una segunda revisión
Comparte el alcance aprobado, las URLs y los informes disponibles, indicando qué afirmación no puedes comprobar. Una descripción y referencias públicas bastan para empezar a delimitar la revisión. Los archivos privados se solicitan por un canal acordado cuando sean necesarios.
La pregunta útil es concreta: qué requisito falta por acreditar y qué evidencia permitiría resolverlo. Con esa información se puede acordar una revisión del informe, nuevas pruebas o una corrección, según el caso, antes de intervenir otra vez en producción.