¿Cómo supervisa este artículo las paradas de la página web? El proximo capitulo. Hoy nos centramos en cómo controlar el colapso de las páginas web.
¿Cuál es la diferencia entre crash y Caton?
La tartamudez significa que la página web tarda en responder temporalmente y que JS no se puede ejecutar a tiempo . Este es también el punto técnico en el que se basa la supervisión de bloqueo de la página web en el último capítulo.
Pero el bloqueo es diferente. Las páginas web se bloquean, las páginas ya no son visibles y el JS no se está ejecutando. ¿Hay alguna forma de monitorear el bloqueo de la página web y reportar el bloqueo de la página web?
Sin embargo, siempre hay una salida del cielo.
cargar y antes de descargar eventos
Después de buscar en Internet, apenas pude encontrar una manera, y finalmente encontré este artículo. Este artículo utiliza los eventos de carga y antes de la descarga del objeto de ventana para implementar el monitoreo de fallas de la página web.
http://jasonjl.me/blog/2015/06/21/taking-action-on-browser-crashes/ jasonjl.me
window.addEventListener('load', function () {
sessionStorage.setItem('good_exit', 'pending');
setInterval(function () {
sessionStorage.setItem('time_before_crash', new Date().toString());
}, 1000);
});
window.addEventListener('beforeunload', function () {
sessionStorage.setItem('good_exit', 'true');
});
if(sessionStorage.getItem('good_exit') &&
sessionStorage.getItem('good_exit') !== 'true') {
/*
insert crash logging code here
*/
alert('Hey, welcome back from your crash, looks like you crashed on: ' + sessionStorage.getItem('time_before_crash'));
}
Una imagen vale más que mil palabras:
Esta solución utiliza inteligentemente el colapso de la página para activar el evento beforeunload .
Cuando se carga la página (el evento de carga ), el estado good_exit se registra como pendiente en el sessionStorage . Si el usuario sale normalmente ( antes del evento de descarga ), el estado cambia a verdadero . Si ocurre el bloqueo , el estado aún está pendiente . Cuando el usuario visita la página web por segunda vez (la segunda una carga de evento), Vista good_exit estado, si todavía pendientes es que podemos concluir última Jim visitado!
Pero este programa tiene problemas:
- Use sessionStorage para almacenar el estado, pero generalmente después de que la página web se cuelga o se congela, el usuario cerrará la página con fuerza o simplemente volverá a abrir el navegador, sessionStorage se almacena pero el estado ya no existirá;
- Si el estado se almacena en localStorage o incluso cookies, si el usuario abre varias páginas web una tras otra, pero no cierra, las tiendas good_exit siempre están pendientes y, cada vez que se abre la página web, habrá un informe de bloqueo.
Este programa fue adoptado al comienzo de la transmisión nacional en vivo y se descubrió que incluso si la página estaba optimizada, el bloqueo no disminuía, y mantuvo una proporción con el PV, solo para darse cuenta de los problemas de este programa.
Solución de estadísticas de fallas basada en Service Worker
Con la popularidad del concepto de PWA, todos están gradualmente familiarizados con Service Worker. Por las siguientes razones, podemos usar Service Worker para monitorear fallas en la página web:
- Service Worker tiene su propio hilo de trabajo independiente, que es diferente de la página web, la página web se bloquea y Service Worker no se bloqueará en circunstancias normales;
- El ciclo de vida del trabajador de servicio es generalmente más largo que la página web, y puede usarse para monitorear el estado de la página web;
- Las páginas web pueden enviar mensajes a su propio SW a través de la API navigator.serviceWorker.controller.postMessage .
En base a los puntos anteriores, podemos implementar un esquema de monitoreo basado en la detección de latidos :
- p1: Después de cargar la página web, envíe un latido para cambiar cada 5 segundos a través de la API postMessage , indicando que está en línea, sw registrará la página web en línea y actualizará el tiempo de registro;
- p2: Cuando la página web se encuentra antes de la descarga , se informa a través de la API postMessage que se ha cerrado normalmente, borra la página web registrada;
- p3: si la página web falla durante el proceso de ejecución, el estado de ejecución en sw no se borrará y el tiempo de actualización se mantendrá en el último latido antes del bloqueo;
- sw: El Service Serviceer comprueba la página web en el registro cada 10 segundos y descubre que el tiempo de registro ha excedido un cierto tiempo (como 15 segundos) para determinar que la página web se ha bloqueado.
Algunos códigos de detección simplificados, para su referencia:
// 页面 JavaScript 代码
if (navigator.serviceWorker.controller !== null) {
let HEARTBEAT_INTERVAL = 5 * 1000; // 每五秒发一次心跳
let sessionId = uuid();
let heartbeat = function () {
navigator.serviceWorker.controller.postMessage({
type: 'heartbeat',
id: sessionId,
data: {} // 附加信息，如果页面 crash，上报的附加数据
});
}
window.addEventListener("beforeunload", function() {
navigator.serviceWorker.controller.postMessage({
type: 'unload',
id: sessionId
});
});
setInterval(heartbeat, HEARTBEAT_INTERVAL);
heartbeat();
}
- ** sessionId ** ID único de esta sesión de página;
- postMessage viene con información para informar los datos necesarios para el bloqueo, como la dirección de la página actual, etc.
const CHECK_CRASH_INTERVAL = 10 * 1000; // 每 10s 检查一次
const CRASH_THRESHOLD = 15 * 1000; // 15s 超过15s没有心跳则认为已经 crash
const pages = {}
let timer
function checkCrash() {
const now = Date.now()
for (var id in pages) {
let page = pages[id]
if ((now - page.t) > CRASH_THRESHOLD) {
// 上报 crash
delete pages[id]
}
}
if (Object.keys(pages).length == 0) {
clearInterval(timer)
timer = null
}
}
worker.addEventListener('message', (e) => {
const data = e.data;
if (data.type === 'heartbeat') {
pages[data.id] = {
t: Date.now()
}
if (!timer) {
timer = setInterval(function () {
checkCrash()
}, CHECK_CRASH_INTERVAL)
}
} else if (data.type === 'unload') {
delete pages[data.id]
}
})
El código es muy simple, no elaborado.
Viabilidad del plan
Compatibilidad:
La popularidad de los Service Workers ya es bastante alta, dado que todos los navegadores domésticos son kernels de Chrome, y la versión ya está por encima de Chrome 45, ha cubierto un número considerable de usuarios. Para el monitoreo, la mayor parte de la cobertura de datos es buena.
Fiabilidad
Esta debería ser la forma en que actualmente sé que puede determinar con relativa precisión el bloqueo de la página web. Sin embargo, nuestra solución aún se encuentra en un entorno de prueba, y compartiremos datos con usted después de estar en línea por un tiempo.
Recomendaciones para fabricantes de navegadores
La lista de Crash del mapa de problemas se puede ver en Chrome visitando chrome: // crashes / . Si el fabricante puede proporcionar una API, cuando se abre la página, ¡puede ser genial saber la última información de bloqueo del usuario!
Recomendación de servicio
