h1

Consejos para mejorar el redimiento de una web I

10 diciembre 2008

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.

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: