Saltar al contenido principal

Guías / Guías de monitorización: cada tipo de comprobación, paso a paso

Cómo configurar la monitorización de velocidad de página

Page Speed carga tu página en un navegador real, desde una ubicación de monitorización real, y vigila cómo se comporta esa única carga de página: qué recursos fallan, cuánta CPU y memoria consume el navegador, y si la página termina de cargar antes de un tiempo de espera que tú eliges. Una comprobación HTTP te dice que el servidor respondió; Page Speed te dice si la página que renderiza el navegador de un visitante se ensambló limpiamente. Si necesitas guionizar un recorrido de varios pasos (iniciar sesión, añadir al carrito, enviar un formulario) en lugar de vigilar la carga de una sola página, consulta en su lugar la guía de la comprobación de transacción: las dos usan un navegador real, pero Transaction Check sigue una secuencia de acciones a lo largo de una sesión.

Configuración principal

Este tipo no tiene captura de pantalla dedicada para su grupo de Configuración principal, pero cada control en él es estándar en todos los tipos de monitor de HostTracker:

  • Domain/IP: la URL o el dominio que cargar. Acepta una URL completa o un dominio simple.
  • Name: una etiqueta opcional que se muestra en tu panel, alertas, informes y widgets. Si se deja vacío, se usa la URL.
  • Interval schedule / Cron schedule: un interruptor segmentado entre un intervalo recurrente simple y una expresión cron completa (presets por hora, diario, semanal, mensual, o sintaxis cron avanzada). El intervalo mínimo disponible depende de tu plan.
  • Tags: etiquetas de texto libre para agrupar y filtrar este monitor.
  • Full Log: guarda cada resultado individual de este monitor sin agruparlos.
  • Open Stats: te deja compartir las estadísticas y registros de este monitor con otros, incluso con personas que no han iniciado sesión.

Este grupo también lleva el interruptor Enabled que pausa o reanuda el monitor.

Configuración de la página

Sección de configuración de la página mostrando el desplegable Device emulation fijado en Desktop (por defecto) y un deslizador Page load timeout fijado en 20 segundos

  • Device emulation: un desplegable que carga la página como lo haría un dispositivo concreto: tamaño de ventana, cadena de user agent, y emulación de entrada táctil. Por defecto es Desktop. La lista de dispositivos disponibles se obtiene en vivo del propio conjunto de capacidades de la flota de agentes, así que las opciones exactas pueden crecer con el tiempo; elige el dispositivo que mejor coincida con cómo navegan tus visitantes la página.
  • Page load timeout: el tiempo máximo permitido para que termine de cargar la página, de 1 a 40 segundos. Si la página no ha terminado para entonces, la comprobación falla.

Los dos ajustes cambian qué significan los números, además de si aprueba la comprobación. Una ventana del tamaño de un teléfono puede disparar un conjunto distinto de imágenes, diseño y scripts que una ventana de escritorio de la misma página, así que los tiempos de una ejecución emulada en móvil no son directamente comparables con una ejecución de escritorio; trata cada ajuste de dispositivo como su propia línea base. El tiempo de espera de carga de página es un techo, no un objetivo: solo define el punto en el que la comprobación se rinde y reporta un fallo. Fijarlo demasiado cerca del tiempo de carga normal de tu página convierte la variación normal en falsas alarmas; fíjalo con margen y vigila el tiempo de carga real en tus resultados en su lugar.

Validación de respuesta

Sección de validación de respuesta con umbrales de Page health (documento/iframe, CPU, memoria, errores de consola, advertencias de consola) y umbrales de Content Load Checks (tiempo de espera de carga de página sin XHR, total, script, hoja de estilos, imagen, fuente, fallos de carga AJAX)

Esto no es una puntuación de Core Web Vitals; HostTracker no está calculando aquí una nota de rendimiento al estilo Lighthouse. En su lugar cuenta fallos concretos a nivel de navegador y límites de uso de recursos, y tú decides cuáles de ellos deberían contar como un Down. Cada umbral de abajo se puede fijar en 0 (o, para CPU y memoria, cambiarse a "sin umbral") para desactivarlo.

Page health:

  • Document/IFrame loading fail threshold: la comprobación pasa a Down cuando al menos este número de documentos o iframes de la página no cargan. Rango 0-50; 0 lo desactiva.
  • CPU usage threshold: la comprobación pasa a Down cuando el uso de CPU de la página (por núcleo) llega a este porcentaje. El deslizador solo cubre 80-100%, así que detecta picos fuertes de CPU y no la carga normal; un control aparte de "no threshold" lo desactiva por completo, que es lo que hay por defecto.
  • Memory usage threshold: la comprobación pasa a Down cuando el uso de memoria de la página llega a esta cantidad, en megabytes. Rango 1-1000 Mb en pasos de 50 Mb, o "no threshold" para desactivarlo, que es lo que hay por defecto.
  • Client-side errors threshold: la comprobación pasa a Down cuando ocurren al menos este número de errores de consola del navegador mientras carga la página. Rango 0-50; 0 lo desactiva.
  • Client-side warns threshold: la misma idea para las advertencias de consola. Rango 0-50; 0 lo desactiva.

Content Load Checks:

  • Page load timeout without XHR: un tiempo de espera alternativo y más corto que se aplica una vez que todas las peticiones XHR/AJAX en segundo plano de la página se han asentado, aparte del Page load timeout principal de arriba. Fijado en 0 (por defecto), solo se aplica el tiempo de espera de carga de página principal; un valor distinto de cero te deja aceptar una página cuyo contenido visible está listo aunque el sondeo en segundo plano continúe.
  • Total load fails threshold: la comprobación pasa a Down cuando al menos este número de recursos, de cualquier tipo, no cargan. Rango 0-50; 0 lo desactiva.
  • Script / Stylesheet / Image / Font / AJAX request fails threshold: el mismo recuento de fallos, desglosado por tipo de recurso, para que puedas tolerar una imagen de anuncio inestable sin tolerar un script roto. Cada uno es 0-50, 0 lo desactiva.

Ubicaciones de monitorización

Sección de ubicaciones de monitorización con un árbol de casillas de Todo el mundo, Norteamérica, Rusia y Europa Occidental, más los desplegables de estrategia de reintento y de reserva de pool

  • Locations: un árbol de casillas buscable de regiones y puntos de monitorización individuales. Elige ubicaciones concretas o deja marcado "All world".
  • Recheck strategy: qué pasa cuando una comprobación detecta un cambio de estado. Por defecto vuelve a ejecutar la comprobación desde varias ubicaciones y acepta el estado nuevo por voto de mayoría, para protegerse de un falso positivo de una ubicación inestable. Alternativas: un número especificado de ubicaciones tiene que confirmar un Down (revela un deslizador de confirmaciones Down de 1 a 7); ningún reintento en absoluto; acuerdo total de todas las ubicaciones de reintento; o acuerdo total para Down mientras que Up solo necesita mayoría.
  • If selected locations are unavailable: "Selected locations only" (por defecto) espera a que vuelvan tus ubicaciones elegidas; "Closest locations" las sustituye por las disponibles más cercanas; "Any location" recurre a cualquier sitio del mundo.

Suscripciones de alerta

Sección de suscripciones de alerta con un interruptor Subscribe all contacts to Up/Down events y una tabla de contactos con interruptores Down/Up/Repeat

Un interruptor suscribe a todos los contactos a los eventos Up/Down en un paso, o una tabla buscable te deja suscribir contactos individuales a Down, Up y Repeat (recordatorios de Down repetidos) de forma independiente. Dejar esta sección vacía significa que no se enviará ninguna alerta para este monitor; el panel te avisa explícitamente si es el caso.

Suscripciones de informes

Sección de suscripciones de informes con un interruptor Subscribe all contacts to Weekly/Monthly reports y una tabla de contactos con interruptores Daily/Weekly/Monthly

El mismo patrón se aplica a los informes de uptime: un interruptor suscribe a todos los contactos a informes semanales y mensuales, o puedes elegir diario, semanal y mensual por contacto individualmente.

Ejemplo resuelto

Supongamos que quieres vigilar cómo se comporta una página de pago para compradores móviles. Elegirías Page Speed, introducirías la URL de la página de pago, y pondrías Device emulation en un perfil de teléfono en lugar de Desktop, ya que la mayoría del tráfico en esa página es móvil. Deja Page load timeout cómodamente por encima del tiempo de carga normal de la página; es un techo pensado para detectar fallos genuinos, no un objetivo de rendimiento. En Validación de respuesta, fija el Document/IFrame loading fail threshold en 1, ya que la página normalmente carga un iframe de pago y quieres saber si deja de cargar. Deja los umbrales de uso de CPU y memoria en "no threshold", ya que una página de pago rara vez consume mucha CPU o memoria y esos umbrales de todas formas solo empiezan en el 80%. Fija el Total load fails threshold en 2 o 3 en lugar de 0, para que un rastreador de terceros inestable no avise a tu equipo cada vez que tiene un fallo pasajero, mientras que una carga genuinamente rota sigue disparando la comprobación. Deja Page load timeout without XHR en 0, ya que las páginas de pago a menudo sondean el estado del pago en segundo plano y eso no debería definir el aprobado o el fallo. Ejecuta la comprobación desde dos o tres ubicaciones cercanas a tus clientes reales, mantén la estrategia de reintento por mayoría por defecto, suscribe a tu contacto de guardia a las alertas Down y Repeat, y configura un informe semanal a una dirección compartida del equipo.

Solución de problemas

  • La comprobación reporta Down pero la página se ve bien cuando la abres tú mismo. Lo más probable es que un contador de fallos de carga (Script, Image, Total, etc.) se disparara por un recurso de terceros inestable, como una red de anuncios o un script de analítica, y no por tu propia página. Comprueba qué contador se disparó antes de asumir una caída real, y considera subirlo de 0 a 1 o 2 si esa inestabilidad es un patrón conocido y tolerable.
  • Los tiempos de carga cambiaron notablemente después de cambiar Device emulation. Es esperable, no una regresión: un perfil de dispositivo distinto cambia la ventana, el user agent y la emulación táctil, lo que cambia qué carga la página y cómo se renderiza. Compara tiempos solo dentro del mismo ajuste de dispositivo.
  • La comprobación sigue alcanzando el Page load timeout aunque la página carga bien en tu propio navegador. La ubicación de monitorización puede estar lejos de tu servidor, o el tiempo de espera está midiendo la carga completa incluidas las peticiones lentas en segundo plano. Sube el tiempo de espera con margen real, y si la página sigue sondeando en segundo plano después de que su contenido visible esté listo, prueba un Page load timeout without XHR distinto de cero.
  • Los umbrales de uso de CPU o Memory nunca parecen dispararse, ni en una página pesada. Los dos empiezan en "no threshold", y el deslizador de CPU solo cubre 80-100% una vez activado. Si te importa vigilar un uso pesado de recursos, mueve explícitamente el control fuera de "no threshold" y elige un valor dentro del rango.
  • Las advertencias de consola de scripts de anuncios o analítica siguen disparando el Client-side warns threshold. Muchos scripts de terceros registran advertencias que no son problemas reales. Deja este umbral en 0, o fíjalo por encima del número normal de advertencias de tu página.

Relacionado

Compruébalo ahora

Ejecuta la comprobación gratuita en tu propio sitio, sin necesidad de cuenta.

Page speed test

Monitoriza esto de forma permanente

Recibe un aviso en cuanto algo falle: HostTracker comprueba desde más de 300 ubicaciones y te avisa por correo, SMS, Slack, Telegram y más.

Funciones de HostTracker

Más en esta sección: Guías de monitorización: cada tipo de comprobación, paso a paso