Una auditoría de rendimiento necesita URLs representativas, contexto de uso y acceso a evidencias de campo cuando existan. También requiere conocer qué tareas son importantes y qué herramientas carga la web. Sin esa información, puede describir una prueba puntual, pero no priorizar con criterio de negocio.
Prepara una muestra que represente el sitio
Incluye portada, servicio, artículo, catálogo y contacto si utilizan plantillas diferentes. Añade una página con contenido pesado o una función problemática. Explica por qué se elige cada URL.
No envíes solo la portada porque sea la página más visible para el equipo. Las consultas pueden empezar en servicios o artículos, y el problema aparecer al completar un formulario.
Comparte condiciones y síntomas comprobables
Una ficha útil contiene:
- URL exacta y tarea que se intenta realizar.
- Dispositivo, navegador y conexión de la prueba.
- Síntoma: carga lenta, bloqueo al pulsar o desplazamiento de elementos.
- Frecuencia observada y pasos para reproducirlo.
- Cambios recientes de diseño o herramientas.
Si hay capturas o grabaciones, elimina información personal antes de compartirlas. No envíes contraseñas dentro de un briefing ni concedas administración completa por defecto.
Distingue datos disponibles y pendientes
Las mediciones de laboratorio ayudan a investigar una carga concreta; los datos de campo describen experiencias observadas durante un periodo. La ausencia de datos de campo debe registrarse, no sustituirse por una estimación presentada como real.
Ejemplo hipotético: una web B2B tiene poco tráfico y recibe quejas al abrir una ficha con muchos documentos. Una prueba controlada puede localizar recursos costosos, aunque no permita calcular qué proporción de compradores resultó afectada.
Ese límite no impide mejorar. Obliga a explicar qué se comprobó y qué sigue sin medirse.
Añade restricciones de operación
Identifica herramientas imprescindibles, sistemas de edición y responsables que pueden aprobar cambios. Retirar un script podría acelerar la página y romper una función necesaria si nadie ha explicado su propósito.
Pide que cada recomendación incluya páginas afectadas, causa probable, prueba, riesgo y validación posterior. Una lista de «optimizar imágenes» no explica qué imagen, dónde ni cómo comprobar el resultado.
Acuerda si la auditoría incluye implementación o solo diagnóstico. La diferencia debe quedar visible en el presupuesto y en el cierre del trabajo.
Qué acceso es proporcional a una primera auditoría
Para una revisión pública puede bastar con URLs y contexto. Si necesitas datos privados, define permiso mínimo, finalidad y duración. No concedas administración del dominio cuando solo se van a consultar métricas.
Pide que el proveedor describa qué no puede verificar sin esos accesos. Esa limitación permite decidir si merece ampliar la investigación.
Incluye responsables de herramientas externas. Un diagnóstico puede encontrar un recurso lento y necesitar comprobar si sostiene una función crítica. Retirarlo sin saber su finalidad podría mejorar la prueba de carga y empeorar la operación que el proyecto debía conservar.
Entrega contexto para recibir un plan útil
La auditoría empieza mejor con una muestra y tareas claras que con una puntuación aislada. Para valorar una auditoría web, prepara URLs, síntomas y restricciones sin compartir accesos innecesarios.