Consejos para mejorar el redimiento de una web II

Como dije en la otra entrega, la mayor parte del tiempo de respuesta se emplea en realizar peticiones HTTP para la descarga de los distintos componentes más que en el propito HTML, por lo tanto si reducimos el número de elementos a descargan se reduciran el número de peticiones sin que esto signifique tener que deshacernos de elementos y, por tanto, perder calidad en el diseño. Las técnicas que se pueden utilizar para eso son:

• Mapa de Imágenes: Si tenemos muchos enlaces con imagenes, tendremos que realizar muchas peticiones para obtener todas las imáganes, en cambio, si usamos un mapa y le asociamos todos los enlaces, sólo tendremos que realizar una petición HTTP para obtener los enlaces. Existen dos tipos de mapas de imagenes, los del lado del servidor y los del lado del cliente, los mas típicos ya que no requieren de ningún back-end.
  Está técnica tiene un problema, el área se tiene que definir a mano y es tedioso y próblematico además de que sólo pueden ser rectangulares y no
  se pueden crear de forma dinámica ya que el DHTML falla en IE.
• CSS Sprites: La idea es que todas las imágenes se combinan en una y mediante las hojas de estilos se muestra la zona de la imagen que se desse. Evidentemente, se reduce el número de peticiones, de forma significativa y son más flexibles que los mapas de imágenes. Así mismo, y aunque parezca mentira, el tamaño de la imagen combinada es menor que la suma de todas las que la forman, ya que, se reduce la información de las imágenes (tablas de color, información del formateo, etc…)
• Scripts y css combinados: Es recomendable usar ficheros externos para los scripts y los css y aunque a veces se tienda a modularizar en muchos ficheros css y js, esto influye negativamente en el rendimiento porque se traduce en más peticiones HTTP. De todas formas, esto nos puede soñar extraño a todos los
  desarrolladores, siempre nos han metido en la cabeza la modularización por todas las ventajas que conocemos, además de que estaríamos cargando
  información innecesaria en la página. 
  Por lo tanto, lo que debemos hacer es, analizar un poco y crear un proceso para generar un fichero que nos devuelva la combinación de ficheros javascript necesaria para una página en concreto.

Todo esto reduce el tiempo de respuesta para usuarios que acceden por primera vez a la página web, es decir, aquellos usuarios que no tengan elementos en caché y demás.

Consejos para mejorar el redimiento de una web I

Llevo muchos años trabajando en el mundo web y uno de nuestros objetivos es mejorar el rendimiento de cara al usuario final, para ellos se usan muchas técnicas, pero las más efectivas son las que mejoran el front-end de la aplicación y la más sencilla. También se pueden realizar cambios sobre el back-end de la apliación, pero esto puede llegar a suponer grandes cambios en el código de la misma y no supone un cambio en tan grande como las técnicas que se utilizan cuando mejoramos el tiempo de respuesta desde el front-end.

Hay muchos factores que influencian en el rendimiento de nuestra web, entre otros tenemos:

• Descarga del html y otros componentes (imágenes, css, scripts…)
• Parseo por parte del navegador del html, javascript y css
• Las peticiones HTTP
  • Hay que hacer especial hincapié en las peticiones pararelas, según la especificación del protocolo, sólo se pueden descargar dos componentes de manera simultánea de un mismo hostname (porque así lo define la especificación) y la mayoría de las webs las resuelve un sólo hostname, con lo que se tienen que hacer múltiples peticiones para la descarga de todos los elementos.

Hay muchas cosas que influyen y es muy díficil definirlas todas, pero lo que si que puedo asegurar es lo que no influye en el redimiento, y esto es la descarga del html, ya que es tan sólo un 5% total del tiempo de carga.

Mi intención es explicar distintas reglas que podemos seguir para la consecucíón de nuestro objectivo, para ello escribiré un mini manual en una serie de posts, de los cuales este es el primero. En el que intentaré explicar un poco los factores más determinantes en el rendimiento de la web del protocolo HTTP.

El protocolo HTTP  lo definieron la W3C y el IETF y está definida en el RFC 2616 y aunque va por la versión 1.1 todavía hay muchos navegadores que usan la 1.0. Éste es un protocolo cliente/servior basado en peticiones y respuestas. El navegador hace una peticion de una URL y el servidor que hospada esa url le manda un
 HTTP request. Todo mediante sencillos ficheros de texto y con diferentes tipos de peticiones, GET., POST, HEAD, PUT, DELETE, OPTIONS y TRACE. De las cuales el más común es el GET y por eso será el que explique con mayor detenimiento. Algunas de las características de las peticiones GET son:

•  Compresión: El tamaño de las respuestas se reduce si el navegador y el servidor soportan  la compresion. Mediante la cabecera Content-encoding mediante las que el servidor averigua si el navegador que realiza la búsqueda soporta la compresión. 
• GET condicionales: Si el navegador tiene una copia en la cache de los elementos pero no esta seguro de que todavía sean validos, manda un GET condicional, si sigue siendo valido, la carga tarda menos y mejora la experiencia del usuario. La forma en la que se suele comprobar si la cache sigue siendo válida es mediante la fecha de modificación, la cuál el navegador conoce basándose en la cabecera Last-Modified, entonces usa la cabecera if-modified-since para madar la fecha al servidor. De esta forma verifica si puede o no la información que tiene cacheada. Si el servidor manda «304 Not Modified» es que puede usarla sin problema.
• Cabecera expires: Esta mejora todavía más la experiencia del usuario, mientras que la anterior necesitaba validación por parte del servidor para usar los componentes cacheados, mediante la cabecera expires, el servidor indica al navegador la fecha en la que los componentes dejan de ser válidos, por lo tanto, si la fecha de los elementos cacheados es anterior a la fecha de expiración, le indica que puede usar los componetes que tiene en caché sin necesidad de «preguntar» al servidor si pueden o no usarse. Lo cual se traduce en menos peticiones y menor tiempo de carga de la web.
• keep-alive:  El protocolo HTTP está construido en base al protocolo TCP, en las primeras versiones del protocolo HTTP cada petición necesitaba abrir una conexión y la gestión de todas esas peticiones realizadas sobre una misma web acarreaba un coste en el rendimiento, ya que, un mismo servidor soportaba mútliples peticiones de un mismo servidor, si lo múltiplicamos por múltiples navegadores realizando peticiones, llegamos a la clara conclusión de que el rendimiento se ve afectado. La idea es no tener que gestionar muchas conexiones y usar la misma para multiples conexiones http de un mismo navegador, por lo que se mantiene abierta la conexión entre un navegador y el servidor hasta que se indique mediante la cabecera Connection Close.

Espero que esta primera entrega os haya resultado interesante.