En primer lugar hay que decir que no todos los formatos de imágenes se ven en un navegador y entre las que sí se ven, algunas son más apropiadas que otras debido a diversos factores.

Si nuestra web tiene varias imágenes que son muy pesadas y tarda en cargar la página, la tortura visual es apreciable, dejamos la página y google » que sabe mucho » intuye el comportamiento humano» y la penaliza en sus resultados. Por ello es muy importante que se optimice la calidad por procedimientos adecuados.

Cuando abrimos un  navegador y escribimos un dominio, en nuestro PC se cargan archivos css y js  así como los html ( o php, asp ), otros como los flv o swf  y las imágenes de la página, junto a una  cabecera  que indica  la  fecha de  caducidad de cada elemento, de forma que si se vuelve a cargar, todo se toma del ordenador y no hay uso apenas de Internet. Esto es muy importante porque  mejora carga de la página, reduce el  consumo de datos del servidor y mejora la experiencia del usuario.

Esas fechas de caducidad de cada elemento ( archivo html, imagen .. ) las podemos cambiar en el servidor por medio del archivo de Apache  .htaccess.

Para ello, descargamos el archivo en nuestro ordenador, lo abrimos con lopeedit o similar y añadimos estas líneas:

Hay que tener en cuenta que el tiempo de espiración se calcula como 60*60*número de horas*número de días. También se  puede indicar como  ExpiresDefault «access plus 7 days» si queremos que sea a los 7 días cuando caduque ese archivo en la caché.

                <ifmodule mod_expires.c> ExpiresActive On ExpiresDefault A3600 <FilesMatch ".(xml|txt|html)$"> # 2 horas de
                vigencia para los archivos xml, txt y html ExpiresDefault A7200 Header append Cache-Control "public" </FilesMatch>

                <FilesMatch ".(gif|jpg|jpeg|png|swf)$"> # 2 Semanas para las imágenes con esas terminaciones ExpiresDefault A604800
                Header append Cache-Control "public" </FilesMatch>

                <FilesMatch ".(js|css)$"> # 3 días para archivos java y hojas de estilo ExpiresDefault A259200 Header append Cache-Control
                "public" </FilesMatch> </ifmodule>

Hacer las pruebas antes y después en esta web para el análisis de

Al página una página en un navegador, empleamos un tiempo valioso en hacer una serie de peticiones al servidor que lo contiene (http request ) que hacen aumentar el tiempo de carga de la página. A mas archivos php, java, jpg, css , etc que se hagan, mas tiempo en cargarse. Reducir el número de requerimientos al servidor hará reducir el tiempo de carga  y así tener una web más rápida. Veremos algunas técnicas para reducir el http request.

1. CSS Sprites. Se utiliza para reducir el número de imágenes descargadas del servidor. De hace una imagen que contenga todas las que se descargan ( por ejemplo, pasamos de 10 a 1 ) y empleando las propiedades background-position y Css  background-image  se toma el «pedacito» de imagen que corresponde a la imagen que queremos mostrar. Aunque no se reduce el tamaño total de las imágenes a descargar, pasamos en este ejemplo de 10 peticiones a sólo 1.
2. Inline images. Con este método se usa el sistema de datos de  URL scheme  para incrustar los datos de las imágenes en el mismo documento html. El resultado es un documento mucho mayor pero ganando en peticiones al servidor y , al usar el sistema de to embed the image data in the actual page. Si aplicamos  este sistema a los archivos CSS que usen cache, se recude considerablemente el tiempo de descarga.
3. Combinar archivos CSS en sólo uno , agrupar los javascript en uno y lo mismo con resto de archivos de la misma categoría reduce el número de http request. El Top ten de las web americanas tienen una media de 7 scripts y dos 2  CSS por página.

Un CDN  es básicamente una red de ordenadores repartidos por el mundo que replican los contenidos del servidor donde tenemos nuestra web ( Servidor original  en el mapa ). El modo de funcionamiento es el siguiente

• El CDN se encarga de almacenar los contenidos estáticos ( regulados por los criterios de Cache ) de nuestra web como imagenes, css, javascript, etc.
• Cuando un cliente hace una petición de nuestra web, todo estos contenidos se cargan desde el CDN más próximo al usuario y los contenidos mas sensibles ( datos que se actualizan con mas frecuencia, como las páginas html, se cargan desde el servidor original.
• El resultado es una experiencia para el usuario mucho más rápida que tener que cargar todos los contendidos desde nuestro servidor que puede estar a miles de Kilómetros.
• El uso de esta Red ( que es de pago ) depende del objetivo de nuestra web. Para una empresa de ladrillos, no tiene sentido porque no vamos a exportar ladrillos a Japón, pero si es de trenes ( catalogo de Talgo ) puede ser muy beneficiosa porque si lo ven desde USA, y la web carga lentamente, no creen ustedes que damos mala imagen en vender trenes de alta velocidad cuando la web va  muy lenta.

 5º Comprimiendo  Componentes con  GZIP

Cuando hacemos una petición de una web al servidor, tenemos una acción de petición-respuesta como la representada en la siguiente gráfica.

En primer lugar, desde el ordenador se hace la solicitud al servidor. Éste la registra, la localiza y manda respuesta al navegador que existe ( código 200 ) y envía la página de unos 100 Kb. En resumidas cuentas, se manda lo que hay si existe y sin comprimir.

La evolución de los navegadores ha sido tal que , hoy por hoy, todos pueden recibir páginas comprimidas para ser mostradas en el mismo y , por supuesto, no es igual mandar por la red un archivo comprimido porque consume menos recursos y ancho de banda.

El procedimiento es el siguiente:

 

En la ilustración tenemos que la petición que hace ahora el navegador tiene un accept-encoding:gzip, o sea que solicita el archivo comprimido «si puede ser». El host lo recibe y como está configurado para servirlo, lo envía con un ahorro considerable de datos ( de 100 a sólo 10 ).

En resumidas cuentas, tenemos que:

• El  navegador envía una cabecera diciendo al servidor que acepta contenidos comprimidos ( o bien método gzip  o  deflate ) de la forma  Accept-Encoding: gzip, deflate.

• El  servidos envía la respuesta si el contenido está actualmente comprimido compressed: Content-Encoding: gzip

Para configurar el servidor, añadimos estas líneas en el archivo .htaccess

                # comprimimos los archivos   html, javascript, txt, css, xml:
                # Vamos a comprimir los mas importantes.
                # se pueden añadir otros mas 
                AddOutputFilterByType DEFLATE text/css
                AddOutputFilterByType DEFLATE text/plain
                AddOutputFilterByType DEFLATE text/xml
                
                
                 AddOutputFilterByType DEFLATE text/html
                AddOutputFilterByType DEFLATE application/xml
                AddOutputFilterByType DEFLATE application/javascript
                # o bein se pueden comprimir por su extensión
                #por ejemplo para los html
                <files *.html>
                SetOutputFilter DEFLATE 
                </files>

Comprobamos si tenemos la web bien configurada

Para ello tenemos algunas herramientas útiles como son

1. gidnetwork.com/tools/gzip-test.php
2. Si se usa firefox, existe una extensión  llamada  Web Developer Toolbar. Una vez instalada, ir a  > Information > View Document Size  y mostrará que archivos vienen comprimidos y cuales no.

6º Archivos CSS en la cabecera

Se comprueba que poner la solicitud ( link ) del archivo css en la cabecera provoca una carga más rápida de la página, por ello es aconsejable situar en la cabecera el enlace al archivo CSS.

Situarlo en la parte inferior puede provocar espacios vacios, errores en la muestra de la web

 

7º ARCHIVOS javascript En el pie de página

Si el punto 6 trataba de poner los css arriba, en este caso, para provocar que la formación de la página sea progresiva y adecuada, con la menor demora, es aconsejable situar los archivos js lo mas tarde posible, ya que al ser archivos que se ejecutan una vez cargada la web, «están molestando» a la hora de la carga inicial. Puede hacer casos en los que no sea posible demorarlos en la carga, pero por regla general, mientras mas abajo mejor.

Otras reglas a tener en cuenta son:

1. Evitar ciertas expresiones CSS que provoque errores en navegadores o estén en desuso
2. Situar los archivos  JavaScript y  CSS fuera del contenido principal ( archivos externos ) e intentar agruparlos
3. Optimizar las DNS
4. Evitar re-direcciones

Herramientas de utilidad:

dominios: gtmetrix.com