Pregunta ¿Tamaño de carga útil precache recomendado?


(Preguntar / responder públicamente en nombre de alguien).

Estoy usando Workbox para generar un trabajador de servicio que precomoda recursos para mi aplicación web progresiva.

¿Me equivoco al ser reacio a precachar ~ 20 mb de JavaScript minificado? Es enorme, obviamente. 20mb parece demasiado. Mi plan era precachear las cosas esenciales y usar el almacenamiento en caché en tiempo de ejecución para el resto.

En otras palabras, ¿cuáles son algunas heurísticas generales para determinar qué se debe y no se debe incluir en la carga útil de precache?


6
2017-07-30 13:52


origen


Respuestas:


Hay muchos matices aquí, y la respuesta correcta se reduce a una mezcla de comprensión de sus usuarios y comprensión de sus recursos.

Consideraciones del usuario

Una de las principales consideraciones es si forzar una descarga de datos de ~ 20 mb es respetuoso de su base de usuarios objetivo.

Si está desarrollando un PWA interno para un cliente corporativo, entonces puede estar bastante seguro de que la mayoría de los usuarios estará en una conexión rápida y no pagará por el megabyte por su plan de datos.

Si se está desarrollando para un mercado que incluye personas con conexiones más lentas y medidas, es una buena idea evitar el precachado automático de grandes cargas útiles. Puede reducir el tamaño de la carga útil previa a la memoria caché o, como alternativa, retrasar el registro del trabajador del servicio hasta que se hayan comprometido un poco con su PWA. En ese momento, si están usando su sitio, es más probable que obtengan valor de las cosas. almacenándose en caché y no se sentirá como un "volcado de datos de unidad de disco".

Entendiendo tus recursos

En la pregunta original, los ~ 20mb se dice que son recursos de JavaScript, y mi suposición es que son todos los activos que se cargan de manera diferida para varias vistas en su aplicación web.

Prefiere muchos activos individuales más pequeños frente a menos activos más grandes agrupados

Más allá de pensar en el costo inicial de precaching, debería preocuparse por el costo constante de las entradas de caducidad y reetiquetado que estaban previamente almacenadas cuando realiza cambios en su sitio a lo largo del tiempo.

Si tiene 20 paquetes individuales precocinados, y cada uno de ellos es ~ 1mb, entonces hacer un cambio en un solo archivo en uno de los paquetes hará que ~ 1mb de datos se transfieran como parte de la actualización de seguimiento. Si tiene 2 paquetes individuales y cada uno tiene ~ 10 mb, el cambio de ese mismo archivo hará que se transfieran ~ 10 mb de datos. El costo de mantener actualizados sus activos precached puede, con el tiempo, superar fácilmente el costo inicial del precaching, así que trate de tenerlo en cuenta cuando realice la agrupación.

Solo activos precacheados para vistas que probablemente se utilizarán

Esto se deduce del punto anterior: intente evitar la precarga de activos con carga lenta que solo serán solicitados por un porcentaje bajo de sus usuarios. Incluso si los activos en sí mismos son pequeños, hay un costo de mantenerlos actualizados que esos usuarios pagan cada vez que realiza un cambio en cualquiera de los archivos que componen esos paquetes. Puede introducir fácilmente una situación en la que, con el tiempo, un usuario descarga y vuelve a descargar JS que nunca terminará ejecutándose.

No precache imágenes (generalmente)

(Esto supone que está considerando precachear imágenes).

Las imágenes, a menos que se utilicen como parte de su interfaz de usuario en muchas páginas, no son excelentes candidatos para precaching. Obviamente, tienden a ser grandes, y si no se pueden cargar porque estás fuera de línea y no están en el caché, entonces ojalá tengas texto alternativo en tu marcado HTML para mostrarlo en su lugar.

El uso de una estrategia de caché de tiempo de ejecución, junto con una política de caducidad de caché, suele ser el mejor consejo para las imágenes.


7
2017-07-30 13:52



Preguntas populares