Lo que los desarrolladores necesitan saber sobre el análisis de rendimiento de HTML5

Comentario: El siguiente artículo fue escrito por un técnico de TI llamado Zhang Liming, y se publicó en la página web de InfoQ. Esta vez, analizó el rendimiento de HTML5 de 9 aspectos diferentes en el texto completo, que vale la pena leer los desarrolladores correspondientes.

Primero, desde la perspectiva de la legibilidad del usuario, hubo muchas cosas que originalmente no fueron entendidas por principiantes por primera vez para ver estas cosas, y el método de declaración HTML5 es obviamente más amigable para los usuarios.

En segundo lugar, la declaración de codificación del documento es muy simple si está en HTML5. Muchas personas preguntan qué es HTML5. Decimos que la forma en que podemos usar HTML5 primero es cambiar primero Doctype, porque muchas páginas todavía están de la manera tradicional. El método HTML5 es compatible con el navegador IE, y puede usarse de IE6 a IE10, y puede ser compatible con navegadores avanzados. Entonces, la forma más fácil de abrazar HTML5 es cambiar Doctype.

Lo siguiente puede no ser algo muy común, pero es algo que prefiero, usando un método de etiqueta más simple. Como puede ver en este nombre, HTML5 se hereda de HTML4. HTML4 tiene modo estricto y modo de transición. HTML5 admite este modo de transición, lo que significa que no puede cerrar algunas etiquetas. Sin embargo, no recomiendo todas las etiquetas, por ejemplo, la etiqueta del cuerpo no está cerrada, lo que no recomendamos. Pero la etiqueta P más comúnmente utilizada es también la etiqueta de la lista LI. ¿Por qué dices esto? En primer lugar, desde una perspectiva visual, este método es un poco más simple. Luego, la clave es que durante el proceso de transferencia de documentos, habrá menos contenido.

La declaración de los atributos de la etiqueta HTML5 admite tres maneras: soportes individuales, soportes dobles y soportes no ramificados. Para reducir el tamaño del documento, elegí el método sin cotizaciones dobles o citas individuales. Sin embargo, debe tenerse en cuenta que suponiendo que sea una declaración de atributos de clase, porque los atributos pueden incluir múltiples clases, y cuando múltiples clases, deben estar encerradas en los soportes. En este sentido, déjame mostrarte una práctica de Google. Google tiene una página que practica completamente lo anterior, reduciendo el tamaño del documento en un 20%, reduciendo la transferencia de documentos HTML en un 20%. Si se practica todo, puede lograr una disminución de entre 5% y 20%. Este es el primer paso, reduciendo el tamaño del documento HTML.

Lo siguiente es sobre la optimización de las imágenes, que siempre son elementos que aman y odian. Porque cuando hay demasiadas imágenes, arrastrará seriamente la velocidad de carga de toda la página. Con respecto a los métodos de optimización de imágenes, hay muchas presentaciones en el libro "Sitio web de alto rendimiento". Para resumir, hay tres puntos principales: usar elfos, optimizar el tamaño de las imágenes y usar URI de datos. No entraré en detalles aquí.

Otra idea de optimización de imágenes es: sin imagen. Abandonar las fotos y abrazar CSS3. Originalmente, necesitaba establecer una imagen con un efecto de esquina redondeado, pero ahora usé Border-Radius en CSS3; Usé la imagen con un efecto de sombra, pero ahora uso Shadow de caja en CSS3; Solía ​​establecer una imagen de fondo de gradiente, pero ahora uso gradiente en CSS3.

3. Pre-FOCHET

A continuación, hablemos sobre la captación previa, que es otra forma de optimización. Nuestras ideas de optimización actuales no son más que pocas. Muchos de ellos son desde la perspectiva de menos cosas, por ejemplo, el tamaño del documento se redujo antes y el tamaño de la imagen se redujo. Muchas imágenes se convierten en elfos, para reducir el número de solicitudes de envío. Para la captura previa, es otra forma de pensar. Carga de recursos temprano. Cuando el usuario va al punto, en realidad se ha cargado, por lo que definitivamente será más rápido.

Hay dos partes para la captura previa: una es la captación previa de los recursos, y la otra es la resolución previa de DNS.

Hay varios puntos a tener en cuenta cuando la precarga de los recursos:

La precarga solo se tirará cuando el navegador esté inactivo, pero no se garantiza que lo tire. Este es un punto muy importante. Porque el navegador en sí tiene un oyente global, que es una interfaz interna. Cuando el aire de navegación está inactivo, ejecutará el navegador cuando esté inactivo, pero esta devolución de llamada inactiva no puede activarse, por lo que no garantiza que se realizará la precarga.

Chrome no admite la precarga de los recursos HTTPS. Por ejemplo, Alipay es una página HTTPS, Chrome no se realizará previamente.

Aunque una página previa a la punta no es visible después de que existe, en realidad está analizando normalmente. Si pre-pullen la página de inicio de sesión, la página de inicio de sesión tiene muchos recursos, como imágenes, archivos CSS y archivos JS. Se analizará normalmente de arriba a abajo. Durante el proceso de análisis, esta página no aparece, pero en realidad existe. En HTML5, puede obtener el estado de la página actual a través de document.visibilityState. Por lo general, la página tiene dos estados, visibles e invisibles, pero ahora hay un nuevo estado llamado estado previo a la renderización. Puede determinar directamente si la página está en el estado prerender por si document.VisibilityState es igual al prerender.

4. Resolución de DNS

El siguiente es la resolución de DNS. A veces, cuando iniciamos sesión en la página, es relativamente difícil detectar dónde puede hacer clic el usuario. Por supuesto, a veces haremos algunos puntos de enterramiento para descubrir que el próximo comportamiento del usuario está en su mayoría. Pero en algunos casos, no sabemos a qué página irá el usuario a continuación, pero sabemos a qué dominio irá. En este momento, puedo pre-parque DNS. Porque, de hecho, hay un largo proceso de resolución DNS en todo el proceso de solicitud de página. Si hacemos esto de antemano, podemos permitir que los usuarios vean esta página.

El siguiente es un caso de papel tapiz Q+. El fondo de pantalla Q+ es un determinado sistema. En primer lugar, toda la arquitectura de Q+ se basa en Web+ Cliente. Lo que estamos viendo ahora es una página web. Aunque es un shell de cliente afuera, su corazón es web. Cuando completamos todo el proceso por primera vez, debido a que hay muchas imágenes, todos los recursos estáticos se asignan a más de una docena de servidores estáticos. En otras palabras, si quiero tirar, tengo que analizar 10 DNS. Este tiempo lleva bastante tiempo, y el momento más lento puede retrasarse en unos segundos, que es algo que podemos sentir a simple vista. Si realiza la pre-resolución DNS, porque no sé qué recurso es, todas las imágenes son aleatorias, por lo que solo podemos decir que trabajamos duro en la pre-resolución del DNS para mejorar su velocidad. De esta manera, puede tomar 2 segundos, y me convertiré en 1 segundo.

A continuación, hablemos sobre la aplicación en Q+. Tendremos muchas cadenas de texto en QQ y Q+, al igual que en QQ, lo que significa que hay una información de la aplicación de texto que empuja en la esquina inferior izquierda de la ventana. Este es el backend se retira de vez en cuando a través de la web, y el backend se saca y luego se muestra en primer plano. Pero en un período determinado, la información operativa total impulsada por todas las aplicaciones en realidad se fija. Si analiza la matriz correspondiente de cada cadena de texto de acuerdo con una aplicación específica, son muy grandes datos en este momento. Debido a que uno aquí tiene alrededor de trescientos o cuatrocientos bytes, desde la perspectiva de la optimización, tiraremos de estas áreas localmente. Luego guarde el almacenamiento local local. Estamos en el mismo dominio, y se puede acceder a toda la información entre las aplicaciones entre sí. Entonces no tirarás de todas las identificaciones que retiraste nuevamente.

También hay un punto que debe prestarse atención aquí. Actualmente, muchos fabricantes de LocalStorage están sincronizados. Si llama a LocalStorage en grandes cantidades, en realidad bloqueará su proceso de representación. En este momento, cuando el usuario arrastra la página hacia abajo, está almacenando datos en este momento y los datos son relativamente grandes. En este momento, el usuario sentirá que su página está muy atascada. Han discutido este tema antes. El diseño de esta interfaz está diseñado de manera asincrónica, y están diseñados como sincrónicos. Esto hará que hagas esta excusa cuando haces más aplicaciones porque hay un proceso de serialización, secuencia al disco. De esta manera, todo el proceso parecerá más lento. Además, LocalStorage puede compartir estos datos entre diferentes ventanas, y se bloqueará en estos datos. Si una gran cantidad de datos llama a esta interfaz local, parecerá estar relativamente atascado. Por lo tanto, no hay una solución particularmente buena en este momento, pero esto es algo para recordar. Incluso si el más grande en este momento es más de las 5 en punto, si usa más de las 5 en punto, hará que el usuario sea muy triste. Porque si llamas a esta excusa y el usuario está arrastrando y usando el mouse, se sentirá muy atascado.

A continuación, hablemos sobre los beneficios del almacenamiento fuera de línea para los usuarios en términos de rendimiento. En primer lugar, el archivo de definición se ingresa al almacenamiento fuera de línea. Todos los módulos del sistema en Q+ tienen un soporte de definición fuera de línea. Es decir, si todas las aplicaciones están desconectadas, aún se pueden usar. Agregue un archivo manifiesto al documento. Manifest es un archivo de definición que declara qué páginas deben almacenarse localmente? ¿Cuáles no necesitan ser almacenados? ¿Cuáles deben reemplazarse si la solicitud falla? Esto se divide en tres partes:

Primero, caché, que debe almacenarse localmente.

En segundo lugar, la red no se almacenará localmente. Volverá y lo solicitará cada vez. Pero debe señalarse aquí que el almacenamiento local y el almacenamiento del navegador son en realidad dos cosas diferentes. Almacenan dos partes diferentes. Incluso si la red necesita decirle a la aplicación que necesito sacarla una vez cada vez, porque al igual que Chrome, su caché de almacenamiento es muy odioso y difícil de eliminar. Debe aclararse manualmente para entrar en vigencia. Entonces, incluso si lo establece para no almacenarlo localmente, el navegador puede almacenarlo en sí mismo porque almacena dos lugares diferentes.

Tercero, Fallback. Si una imagen falla, es 404. Entonces, ¿qué imágenes deben usarse en su lugar? Creo que esto es más divertido.

¿Cómo establecer Maeifest? Hay tres cosas a tener en cuenta sobre Manifest:

Restricción homóloga manifiesta;

El tipo MIME debe ser Text/Cache-manifest, lo cual es estándar y no entrará en vigencia si está en otros formatos;

Chrome, si desea ver si esto entra en vigencia, puede ingresarlo en el navegador a través del pseudo-propocol Chrome, Chrome: // AppCache-alternals.

Sobre cómo actualizar el caché de la aplicación. ¿Por qué necesita almacenamiento fuera de línea? Almacenar fuera de línea localmente. Cuando el navegador sabe que tiene almacenamiento fuera de línea, primero irá al directorio de almacenamiento fuera de línea para averiguar si este recurso ha sido almacenado en caché. Cuando haya sido almacenado en caché, obtendrá el recurso directamente desde aquí y no enviará otra solicitud. Debido a que la solicitud del navegador es así, cuando hay almacenamiento fuera de línea, incluso la solicitud no se enviará, por lo que será más rápido. Si a veces necesitamos actualizar, ¿qué debemos hacer cuando actualizamos?

Los usuarios pueden borrar manualmente el caché del navegador, y el almacenamiento local se borrará automáticamente en este momento.

La modificación de cualquier contenido de Manifest es una forma más recomendada y también es la forma en que lo usamos en línea. Es decir, podemos modificar los proyectos específicos en el interior, pero es mejor modificar los comentarios aquí, porque cada vez que publico, publicamos automáticamente el mecanismo y solo lo comentamos y modificamos cuando publiquen. De esta manera, cada vez que se publique el contenido, se sincronizará con el área local del cliente en tiempo real;

Ejecutar a través del programa y el programa es Window.applicationCache.update (). Significa que quiero operar el almacenamiento fuera de línea. De hecho, a veces lo llamo almacenamiento de aplicaciones porque su semántica es el almacenamiento de aplicaciones. Vamos a actualizar manualmente el almacenamiento de la aplicación.

6. Trabajador de Web

Siguiente trabajador web. Web Worker es un proceso JS de múltiples subprocesos. De hecho, si no tenemos escenarios de aplicación en línea, no hablaré de ellos. Pero podemos hablar sobre los escenarios de aplicación específicos que he visto.

Primero, déjame presentar cuál es la webwork? Es un hilo de nivel del sistema operativo. Antes, imitamos múltiples subprocesos, pero de hecho abrimos una ventana más. Pero ahora, el navegador en sí lo proporciona, lo que traerá más conveniencia a la operación y es una forma de hacer que todo nuestro documento sea más pesado y no muy recomendable.

Luego, WebWorker tiene capacidades de acceso limitadas y no puede acceder a muchos objetos globales. Por ejemplo, no se puede acceder al objeto Documnet. El escenario más adecuado para WebWorker son las operaciones informáticas intensivas en CPU. Cuando estábamos jugando antes, usamos Box2d. Mucha gente ha oído hablar de eso. Implica muchos cálculos, es decir, todos los objetos a continuación en toda la página necesitan calcular su relación de colisión, que es muy grande. Sin embargo, si se ejecuta en el proceso JS actual, el cálculo es grande, y una vez que se calcula el cálculo, la página completa será muy tartamudeante. Sin embargo, si usa WebWorker para hacerlo, es un proceso asincrónico que se envía en tiempo real y puede hacer otras cosas durante el proceso de cálculo, que es múltiples subprocesos.

Hablemos de la API del dispositivo. Creo que lo más importante de la API del dispositivo es el rendimiento, y también es la API más temprana actualmente implementada. Una es la conexión, que es el ancho de banda de la red. ¿Cuál es la función de esto? En este escenario en China, es necesario recordar que las velocidades de Internet de muchos usuarios aún son muy bajas. Esperamos que cuando la velocidad de Internet de los usuarios sea baja, puedan degradar automáticamente a una solución relativamente baja. No podemos hacerlo si usamos la tecnología existente. Pero podemos usar la API del dispositivo. Porque sabemos que esta información se puede obtener del dispositivo. ¿Cuál es su banda ancha? ¿Qué es la banda ancha? Lo que podemos hacer cuando sea. Por ejemplo, cuando la banda ancha es buena, uso imágenes de alta definición. Cuando la banda ancha sea relativamente baja, use imágenes con menor claridad.

8. Batería

El siguiente es sobre la batería. Creo que desde una perspectiva de rendimiento, se trata principalmente de poder. Si la energía de la batería del usuario es relativamente baja, creo que debería intentar hacer menos cosas. La tecnología de batería del teléfono móvil en sí aún no ha realizado avances. Creo que hacer que la aplicación se vea más de alto rendimiento también es lo más destacado de la publicidad.

9.Canvas

El siguiente es el lienzo. Hablemos de varios puntos de optimización de rendimiento del lienzo. Si usa estas cosas, el rendimiento mejorará 10 veces.

Primero, cada lienzo es un lienzo. Cuando queremos renderizar un gráfico, podemos colocarlo. Al igual que dentro de PS, es una, dos y tres capas. Muchos usuarios imitan directamente todo en una capa al hacer juegos, y todo debe actualizarse una vez que se actualicen. Pero si lo coloca, coloca el fondo en la capa de fondo y el carácter del papel. De esta manera, cuando quiero actualizar el rol, solo actualizaré el rol, y la capa de fondo no necesita ser cambiada. Como la CPU hace menos, el rendimiento mejorará naturalmente.

Segundo, context.drawimage. No escalar la imagen. Cometimos un error al principio. Las imágenes hechas por nuestros artistas siempre son inconsistentes con nosotros, y luego queremos escalar la imagen. Debido a que el tamaño de la imagen del dispositivo en sí es así, debemos escalar la imagen por relación. Después de acercarme a la imagen, descubrí que en dispositivos de gama baja, por ejemplo, iPad o iPhone estarán muy atascados. ¿Por qué? Solo realice el análisis de código. Al usar este método, costará mucho.

Tercero, requestanimationFrame. Este es un método específicamente optimizado para la representación. Su propio principio es este: cuando el navegador pasa un marco, este método se activará. Cuando lo activo, el lienzo consigue que el navegador esté listo para hacer el siguiente cuadro. Si usa el método tradicional, no considerará más de sus cosas. Solo sabrá cuánto tiempo he pasado y lo ejecutaré. Si el usuario se bloquea antes y ejecuta este método cada 10 segundos, en 10 segundos, el trabajo anterior no se ha completado y luego el trabajo se pospondrá. Está optimizado para que la animación se vea más suave, porque cada cuadro le dice que puede hacer algo. (Texto: infoq)