Jpeg Tran

Las siguientes instrucciones han sido probadas bajo OSX Lion 10.7.2, y debería funcionar sin mayores cambios en la mayoría de las distribuciones GNU/Linux.
Primero descargamos el programa desde http://www.ijg.org/
Abrimos una terminal para ejecutar los siguientes comando
$ cd
$ cd Downloads
$ tar -xvzf jpegsrc.v8c.tar.gz
$ cd jpeg-8c
$ ./configure –prefix=/usr/local/jpegtran
$ make
$ sudo make install
Esto creará el archivo jpegtran dentro de la carpeta /usr/local/jpegtran/bin/ y además creará un link simbólico que nos permitirá ejecutar el comando desde cualquier directorio.
Lo siguiente es empezar a utilizarlo sobre algún archivo JPEG. Para eso utilizamos:
$ jpegtran -optimize -copy none -outfile optimized.jpg -progressive -perfect original.jpg
Esos son los parámetros que recomendamos para este comando. Reemplaza “optimized.jpg” por el nombre que deseas para tu archivo y “original.jpg” por el nombre del archivo existente que deseas optimizar.

PNGOut

En el caso de los archivos de tipo PNG, vamos a utilizar PNGOut, el cual esta disponible para OXS, Linux y originalmente para Windows.
Cabe señalar que antes de esta aplicación también hicimos pruebas con OptiPNG, sin embargo, para el caso de la imagen de prueba que utilizamos el resultado era siempre “% is already optimized.” y en el mejor configurando con otros argumentos generaba una ganancia de 2%.

Para instalar PNGOut debes descargarlo desde http://www.jonof.id.au/kenutils
Y ejecutar los siguientes comandos:
$ tar -xvzf pngout-20110722-darwin.tar.gz
$ cd pngout-20110722-darwin
$ sudo ln -s /Users/cvences/Downloads/pngout-20110722-darwin/pngout /usr/local/bin/
Con esto podemos ejecutar el comando pngout desde cualquier directorio en la terminal.
Al hacer las primeras pruebas con PNGOut, la ganancia para un archivo de 940 Bytes fué de más de 89% al generar un archivo de 104 Bytes.

Conclusión

Idealmente, antes de integrar las imágenes con el sitio web estas deben ser procesadas por la herramienta correspondiente para que se genere una imagen con la misma resolución pero con un peso mínimo, sin todos los meta-datos innecesarios para un navegador de internet.
Esto va a resultar en un sitio más ligero y que reducirá la velocidad de carga para los visitantes del sitio web.

Desde hace ya más de diez año en lo que respecta a web, se han generado una cantidad basta de protocolos y estándares para trabajar con elementos de diseño visual. Algunos se siguen utilizando a la fecha y otros debido a la reducción de costos del hardware han dejado de tener sentido.

Desde el estándar RGB web-safe para estandarización de tonos de color en los diferentes navegadores, tipografías “embedidas”, los diferentes formatos de imágenes y animaciones interactivas.

En esta ocasión vamos a hablar de dos formatos de imagen utilizados en web. PNG y JPEG, pueden encontrar en internet varias referencias acerca de sus siglas, historia, tipo de compresión y uso recomendado.

Pero en esta ocasión vamos a hablar de su impacto en la carga de un sitio ya que más del 90% del peso de un portal es gracias a las imágenes que en el se muestran. Un archivo de texto por muchos caracteres que contenga siempre tendrá un radio de compresión mucho mayor al de una imagen, es por ello que encontramos diferentes formatos y cada uno con muchísimas opciones al momento de generar un archivo.

El “default” que podemos esperar al recibir una imagen que vamos a utilizar en un navegador es un formato PNG, JPEG o GIF, que un diseñador envíe una imagen para utilizar en web en formato BMP equivale a ver in índex.php en la URL de un sitio web.

A partir de ahí lo mínimo que se espera al momento de generar una imagen es que esa imagen se pase por un proceso de optimización. ( ⎇ ⇧ ⌘ S )

Pero en el caso de un proceso de compresión “lossless”, ¿como sabemos si hemos alcanzado el nivel óptimo de optimización?

Aquí es cuando utilizamos “Google Page Speed,” ya sea en su versión “online” o como “plugin” para Firefox (o Chrome)

VIDEO BVY4ZZM17

Como podemos ver hay varios archivos en esa lista de los cuales, “Google” nos recomienda aplicar compresión (no hacer un zis).

Sin embargo, estos archivos ya están en formatos “lossless” y ya se les aplicó el proceso de optimización de Photoshop.
En la segunda parte de esta nota vamos revisar la instalación de dos herramientas que nos permitirán aplicar una compresión aún mayor a los archivos JPEG y PNG bajo OSX/GNU Linux.

Cuando se comienza un proyecto nuevo siempre se lleva un proceso de análisis, de planificación de “User Stories”, estas las calificamos con respecto a una dificultad y luego hacemos una proyección de tiempos conforme a las velocidades de desarrollo de los los recursos que estarán involucrados en el proyecto, para hacer un estimado del tiempo en que estará terminado, y como parte del proceso de tareas esta el elegir las herramientas de desarrollo, y aquí viene una pregunta que muchos nos llegamos hacer en su momento usar o no un “framework”, algunas veces es útil otras no tanto, bueno aquí algunas ideas de por que creo eso.

Si ya esta todo solo falta a
rmarlo o Es fácil construir un proyecto usando un “framework”

A veces se tiene la idea de que el “framework” al ser un conjunto de herramientas que tenga capacidad agrupar algunas librerías para facilitar el desarrollo, solo es cosa de activarlas y en unos minutos hechas a andar el proyecto. Si es verdad que por lo regular un “framework” te ofrece herramientas para crear modelos, vistas y controladores mas rápido, pero aun así no se considera que se deben adecuar a las necesidades propias del negocio, salvo que hagas un proyecto de “demo” donde no te importa dejar muchos cabos sueltos. Si ayuda pero siempre faltara ese ingrediente adicional que es el ingenio de conjuntar todo para que funcione.

Ahora es común que si reduzca el tiempo cuando se hace un proyecto similar pero mas que el ”framework” es la experiencia sobre el tema.

Se aumenta la velocidad de desarrollo usando un “framework”

Es complicado poner se medir si la productividad se incrementara solo por usar un “framework”:
Si no se tiene experiencia en el “framework” implica invertir tiempo en aprenderlo, y no garantiza conocerlo del todo, por lo regular solo se aprende lo que se necesita saber al momento, en caso de profundizar demasiado se corre el riesgo de nunca comenzar y hacerse expertos en el tema.
Si se tiene experiencia no siempre será sobre el mismo tipo de proyecto, entonces puede ser que aun nos queden cosas por aprender como se mencione antes casi siempre se aprende lo necesario para el proyecto actual, es complicado que aprenda sobre un tema si no se aplica, ya que lo bueno o malo sale en un proyecto real.

Usar un Framework propio al fin que se le puede hacer lo quiera sin limites

Aquí el desarrollador se tiene confianza de más en su código de siempre y trata de usarlo en varios proyectos hasta que arma su propio “framework” que aunque rústico pues al ser un conjunto de librerías que funcionan bien para los proyectos que maneja, es muy regular que no se actualicé y genere problemas de seguridad, problemas de validaciones, incompatibilidad nuevas versiones de sus dependencias.

Usar un “framework opensource” es mejor por que lo soportan miles de manos

Pues si es verdad de que muchas personas podrían aportar pero no todos lo hacen la mayoría son usuarios, y de esos no todos regresan las problemas se quedan con el desarrollador que lo encuentra a espera de que alguien mas lo reporte. Ahora así como gente que lo soporta esta la gente que lo explota para “hackear” sitios, aprovechando que rara vez la gente actualiza su “framework” después de entregado el proyecto y solo lo actualiza cuando sucede un problema.

Las soluciones dadas por un “frameworks” son difícil de adaptar a un proyecto real

Cuando usamos un “framework” nos da tanto como facilidades como restricciones, que son las reglas del juego al construir un proyecto usando un “framework”, por lo regular el trabajo es poder adaptar una solución a las reglas de ese juego, pero tampoco es una regla que tengas desarrollar un proyecto usado 1 solo “framework” o que el 100% sea hecho usandolo, en casos donde el “framework” no te permita hacer algo siempre tendremos otras formas de resolverlo.

Que un “framework” es eterno

Contrario al anterior existen quien cree que un “framework” sirve para todo, lo cual no es siempre es verdad puede ser adaptado en algunos casos, pero esto no siempre es posible o si se puede es complicado, pero para eso existen otros “frameworks”.

“Framework” es único y no existe otro que haga los mismo.

Extrañamente algunos “frameworks” les gusta reinventar la rueda y son creados solo por que pueden hacerlo sus creadores, y para demostrarse algo a si mismos. Algunas veces veras que muchos “frameworks” hacen lo mismo o muy similar pero sus diferencias radicaran en su “performance”, por situaciones de licencia, por que desarrollador ama un lenguaje y se siente inspirado lo que hace un “framework” para otro lenguaje de programación, en su facilidad para crear proyectos de cierto tipo, con lo cual se dificulta modelar proyectos con características distintas del proyecto original por el cual fue inspirado. En general es bueno investigar un poco de la historia del “framework” pasa saber si nos brinda una solución o es un potencial problema.

Que es mejor hacer un “framework” propio que usar alguno ya construido

Las ventajas de hacer un “framework” es que podemos hacer como deseemos, pero implica un mayor gasto de tiempo y esfuerzo que regularmente recae en los costos del proyecto. Por lo regular un “framework” tiene un equipo atrás ya sea o no apoyado por una empresa privada, por lo regular se tiene la ventaja de muchos desarrolladores en el mundo lo pueden usar y si bien no todos regresan código o aportan al mismo, si es probado por ellos y los errores o problemas que se presentan llegan por medio de foros, o el sistema de “bugs” en el mejor de los casos. Aparte que se mantienen al día sobre nuevas versiones de sus sus dependencias, cosa que un “framework” propio casi siempre es dependiente de las versiones de los paquetes que use, ya que por lo regular no se le dará un mantenido a largo plazo y eso implica que cuando quieres usar ese “framework” de nuevo puedes estar usando software viejo o tendrás que dedicar tiempo a actualizar las librerías (en caso de que se puedan actualizar sin que haya cambios mayores).

Que un sitio o aplicación web se vea y funcione de manera correcta en los principales navegadores y sistemas operativos que existen, es una parte escencial del proceso de su desarrollo y optimización, y un punto clave en su grado de éxito y supervivencia.

No hay nada mejor que realizar estas pruebas en cada navegador y sistema operativo real, utilizando varias máquinas e instalaciones de navegadores según se requiera, pero obviamente no siempre se dispone de esta posibilidad (casi nunca, en la mayoría de los casos). Por tal motivo, existen diferentes servicios y herramientas web que brindan este servicio a través de internet, de forma gratuita o con planes pagos.

Lo que sigue es una selección de las principales y mejores opciones, según nuestro criterio y evaluación.

Servicios y herramientas web

Adobe BrowserLab

https://browserlab.adobe.com/en-us/index.html

• Es un servicio gratuito que permite testear en diferentes navegadores y sistemas operativos, incluyendo Chrome, Safari, Internet Explorer y Firefox, Windows y Mac OS X.
• Ofrece diferentes maneras de ver los resultados de las pruebas (una vista, vista espejada) y un orden personalizado de los navegadores que deseamos probar.
• Pueden guardarse los screenshots como archivos JPG.
• Se requiere un Adobe ID para utilizar el servicio (se solicita mediante registro gratuito).

Saucelabs

http://saucelabs.com/

• Servicio pago, con opción gratuita (la cuenta gratuita requiere registro para utilizar todos los navegadores disponibles).
• Sistemas operativos disponibles: Windows y Linux.
• Se realiza el test accediendo al navegador en forma remota, por lo tanto se puede navegar por el sitio que estamos probando, chequeando su funcionalidad y componentes dinámicos.
• Tiempo de uso: 20 minutos por cada sesión de prueba (40 minutos en total en la cuenta gratuita).
• Guarda un video de cada sesión de prueba, que se descarga al finalizar.

IE NetRenderer

http://ipinfo.info/netrenderer/

• Servicio gratuito que permite chequear como es renderizado un sitio por Internet Explorer 9, 8, 7, 6 ó 5.5.
• Muestra diferencias entre Internet Explorer 6 y 7, superponiendo ambas imágenes a través de dos modos (Mezcla y Diferencia).
• Sólo captura la pantalla con resolución de 1024 x 768 px.
• También es un complemento para Firefox, útil para los usuarios de Mac:https://addons.mozilla.org/es-es/firefox/addon/ie-netrenderer/

BrowserStack


http://www.browserstack.com/

• Servicio pago, con un plan gratuito con límite de 60 minutos de testeo.
• Se testea en forma remota en los navegadores, sólo en Windows por el momento.
• Al ser remoto permite probar Ajax, CSS, JavaScript, Flash y otros elementos dinámicos del sitio.
• Ofrece herramientas para debugueo (Firebug, Firebug Lite, IE Developer Tools, Web developer) instaladas en los navegadores.
• Modo de testeo local, para sitios o páginas que están en nuestra máquina o un servidor local que utilicemos.
• Permite seleccionar el navegador y la resolución de pantalla (800 x 600, 1024 x 768, 1280 x 1024).

BrowserCam

http://www.browsercam.com/

• Es un servicio pago, con diferentes planes. Se puede probar gratis (sin acceso remoto, durante 24 hs. o 200 pantallas).
• Ofrece captura de navegador en: Mac OS X y Windows, Firefox, Chrome, IE, Safari, Opera, Netscape, Mozilla, Camino y AOL.
• Dispone de captura de dispositivo móvil (iPhone OS, Android, Blackberry y Windows Mobile).
• Funciona mediante acceso remoto, a través de una conexión VNC, para chequear el funcionamiento de javascript, DHTML, formularios y otros elementos dinámicos.
• Ofrece captura de pantalla completa, hasta 8 páginas de largo.
• Colaborativo: las capturas se archivan en nuestra cuenta y pueden compartirse con otros usuarios del sistema.

Programas de escritorio

Mobilizer

http://www.springbox.com/mobilizer/

• Aplicación gratuita para Mac, funciona con Adobe Air.
• Permite probar sitios web o archivos locales en diferentes dispositivos móbiles: Palm, HTC, Blackberry, iPhone.
• Los resultados de las pruebas se pueden exportar como archivos PNG.

Navegadores a tener en cuenta

Al momento de definir qué navegadores tener en cuenta en las pruebas, todo dependerá del tipo de sitio, el tipo de usuario al que se dirije y de las tecnologías que se utilicen.

Hay navegadores antiguos (como Internet Explorer 6 y 7) que no soportan tecnologías web nuevas, por lo cual en ese caso no los deberemos tener en cuenta y tenemos que decidir si se ofrecerá una versión alternativa del contenido o un mensaje donde se avise al usuario de la situación (“Estás usando un navegador antiguo”) y se le ofrezcan los links de descarga de los navegadores soportados.

Se recomienda estar atento a las estadísticas de nuestro sitio para ofrecer una experiencia óptima a nuestros visitantes. Es decir, conocer a nuestros principales usuarios y optimizar en base a eso el funcionaminento de nuestro sitio.

Este es un resumen de las estadísticas globales de uso de navegadores y sistemas operativos, según StatCounter.com, desde octubre de 2010 a octubre de 2011.

Navegadores de escritorio

• Internet Explorer 8 – 28,27 %
• Firefox 3.6 – 16,95 %
• Internet Explorer 7 – 8,11 %
• Internet Explorer 6 – 4,33 %
• Firefox 4 – 3,85 %

Navegadores móbiles

• Opera – 21,85 %
• iPhone – 16,78%
• Android – 16,65 %
• Nokia – 16,11 %
• Blackberry – 13,23 %

Sistemas operativos

• Windows XP – 46,32 %
• Windows 7 – 31,81 %
• Windows Vista – 13,36 %
• MacOSX – 6,44 %
• Linux – 0,78 %

Acortar camino: Buen código y validación

A modo de conclusión enumeramos una serie de pasos que recomendamos seguir para optimizar el tiempo y el trabajo de desarrollo y testeo de sitios y aplicaciones web, con el objetivo de conseguir el mayor grado de compatibilidad con los navegadores y sistemas operativos.

1. Escribir el código de nuestro sitio o aplicación siguiendo las prácticas y estándares recomendados por el W3C (http://www.w3.org/standards/).
2. Validar el código HTML (http://validator.w3.org/) y CSS (http://jigsaw.w3.org/css-validator/).
3. Corregir errores detectados en la validación.
4. Testear en los diferentes navegadores y sistemas operativos a través de las herramientas y servicios disponibles.
5. Realizar los ajustes y correcciones necesarias (HTML, CSS, etc.).

Podemos encontrar plugins que hacen lo que necesitamos dentro del sitio web pero no basta con eso y a continuación se mostrarán algunos puntos que debes considerar para elegir un plugin que no solo haga lo que necesites, sino que te proporcione un buen funcionamiento.

Documentación

Es muy importante verificar que el plugin que vamos a elegir resuelva la necesidad de nuestro sitio web, para eso hay que revisar bien su documentación, las FAQS y el manual de instalación, así como cualquier documento anexo al plugin, esto nos va a servir para conocer sus características, requerimientos, alcances, limitantes, ventajas, desventajas y así poder evaluar de entrada si el plugin realmente nos va a servir. El ranking o calificación y los buenos comentarios aumentan la confiabilidad del mismo.

Rendimiento

Esto es algo que no se debe pasarse por alto para que nuestro sitio trabaje de la forma más eficiente, si eres programador deberás hacer las pruebas pertinentes, si no lo eres deberás buscar la mayor información posible acerca del plugin como comentarios de usuarios o programadores acerca del rendimiento o problemas que ocasiona el plugin, si tienes dudas de su uso es recomendable consultar a un experto o solicitar directamente al creador del plugin para que despejes tus dudas.

Hay que cuidar que un plugin justifique cada una de las peticiones al servidor que haga como lo puede ser la carga de css, javascript y cualquier otro script que incluya, un buen plugin mantiene el mínimo de peticiones al servidor y lo hace solicitando únicamente lo que va utilizar en ese momento y no haciendo solicitudes al servidor que no se utilicen o que sean redundantes. Adicionalmente el plugin debería agregar correctamente el css en el header y el javascript en el footer, esto si nos referimos a un plugin que trabaje de forma independiente a otros plugins.

El diseño del backend en un plugin es muy importante, si utiliza un sistema de base de datos asegurate que las peticiones a la misma estén optimizadas para que sean lo más rápidas posibles y no generé un consumo excesivo de recursos. Debemos cuidar que las solicitudes a base de datos que haga el plugin no afecte la información generada por wordpres o a algún otro plugin.

Seguridad

Mantener un sitio seguro es primordial, para esto primero debemos siempre verificar que la versión del plugin que vamos a descargar sea la más reciente, la constante mejora y corrección de un plugin garantiza que su implementación presente mayor seguridad y estabilidad. Revisa que el plugin que vas a descargar se encuentre en el repositorio oficial de wordpress, cuando un plugin no se encuentra ahí significa que no está validado y puede representar algún riesgo su uso.

Después si te es posible, debes hacer distintas pruebas para determinar que el sitio no es vulnerable con el plugin instalado, en caso de encontrar alguna vulnerabilidad es necesario reportarlo al autor del plugin para que trabaje en una solución. Un plugin que es muy popular tiende a ser objetivo de hackers con malas intensiones, pero también obliga a que los autores del plugin aumenten la protección del plugin o lo mejoren.

Integridad

Un plugin debe respetar la integridad de tu instalación de wordpress por lo que debemos cuidar que su implementación no afecte la estructura de tu wordpress, los archivos de wordpress y la información básica del sitio debe permanecer intacta para que nos garantice un uso óptimo del sitio y que permita implementar de forma segura y efectiva mejoras y actualizaciones en el sitio.

En resumen para elegir un plugin de wordpress de la forma más adecuada debemos conocerlo bien y revisar que siempre presente un buen rendimiento, sea seguro y respete la integridad del sitio.

Desarrollamos sitios y sofware potentes, creativos y fáciles de usar. Usamos tecnologías de vanguardia y diseño de última generación para crear sitios y aplicaciones modernas, inteligentes. Nos preocupamos
por la interacción del usuario final, garantizando una experiencia placentera y una visita convertida en acción.

Rentable

Usted puede obtener y utilizar WordPress de manera gratuita. Esto significa que sus desarrolladores tardaran menos tiempo en desarrollar su sitio, menos tiempo de desarrollo es igual a menor costo.

CMS

Lo que muchas empresas no entienden del todo, es que, WordPress en mucho mas que una simple y amigable herramienta de blogging. WordPress es también un potente CMS que se puede utilizar para actualizar de manera sencilla todo tipo de información en su Sitio Web.

SEO

WordPress por default provee un excelente soporte para el SEO (Search Engine Optimization), además usted puede instalar en su sistema extensiones (plugins) que mejoran de forma exponencial la compatibilidad entre WordPress y los motores de búsqueda.

Extensiones

También conocidos como plugins, son complementos independientes que pueden ser agregados a su sistema de una forma muy sencilla, existen alrededor de 16,000 plugins gratuitos en los repositorios públicos de WordPress pero si es necesario puede pedirle a su desarrollador que cree un plugin personalizado y explícitamente  para adaptarse a las necesidades de su sitio y negocio.

Contenido

Al usar WordPress usted no necesita tener conocimientos técnicos para poder actualizar el contenido de su sitio web. Una vez que WordPress está configurado y funcionando puede usar el “Editor de Texto Simple” interno para poder hacer sus cambios de forma rápida y sencilla, olvídese de pagar de nuevo por una actualización.

Popular

Muchos desarrolladores Web alrededor del mundo reconocen los beneficios de usar WordPress y muchos de ellos se centran específicamente en esta plataforma. Así que si alguna vez usted necesita un experto en WordPress puede estar seguro que lo encontrará rápidamente.

Blog

Puede usar WordPress como CMS pero esto no lo limita de tener su propia sección de blog, Un Blog corporativo es la llave para mantener una relación cercana con sus clientes. Además de que la integración con de su Sitio Web y su Blog será completamente transparente.

Soporte

WordPress es soportado por una larga base de desarrolladores. Estos desarrolladores constantemente mejoran las características de WordPress, así que, al usar WordPress usted puede beneficiarse al tener los últimos avances de tecnología del mercado en su Sitio Web.

Social Media

WordPress se puede integrar fácilmente con otras plataformas sociales, tales como, Facebook, Twitter, YouTube por decir algunas, con esto tenga la seguridad que el contenido que publica en su Sitio Web será exponencialmente  distribuido a través de estos canales.

Móvil

WordPress al utilizar los estándares para desarrollo web (W3C) puede ser visto desde cualquier dispositivo que cuente con un navegador, que al día de hoy, son casi todos. Literalmente su contenido y sus productos estarán a un click de distancia de sus clientes.

MultiSitio

WordPress en comparación con cualquier otro de sus competidores cuenta con la facilidad de administrar varios sitios desde una sola instalación, es decir, WordPress es MultiSitio. Por ejemplo, usted tiene su negocio el cual cuenta con varias sucursales, con WordPress MultiSitio puede dar de alta sitios independientes por cada sucursal, pero con la gran ventaja de hacerlo desde una misma instancia de WordPress, así usted no tendrá que volver a configurar WordPress desde el principio.

Estos desde mi punto de vista son las 10 + 1 razones para que adopte a WordPress como CMS.

En la siguiente imagen, ayudados del panel de Red de Firebug (http://getfirebug.com/) podemos observar 10 requests en total, con un peso de 117.7 KB y un tiempo de carga de 364ms para activar el evento onload de la página.

Esto implica que por cada visitante que llegue a nuestra página, se consumirán 10 conexiones al servidor para traer cada uno de los elementos de la página. Idealmente deberíamos de tener un solo request al servidor origen y varios a los servidores estáticos.

Si traducimos eso a millones significaría que por cada millón de visitantes a nuestro sitio, requeriremos un servidor que permita resolver 10 millones de requests lo más rápido posible. De acuerdo a lo que aquí se plantea, el ideal es surtir 1 millón de requests para un millón de visitantes. Definitivamente los costos de hardware se reducirían considerablemente, ya que crecer de uno a diez millones de visitas sería un número bastante grande en términos de SEO, sin embargo el incrementar el consumo de recursos por cada página en el servidor elevaría los costos de hosting.

Esta reducción de requests y la división de llamadas a servidores estáticos se deben optimizar con una combinación de código y diseño para que sean los menos posibles.

Enter the CDN

La manera más sencilla de reducir la carga contra el servidor y de esta manera dar un mejor servicio con los mismos recursos es dividir la carga a un CDN. Un CDN server tiene la característica de ser un servidor web muy ligero y con un alto grado de caching en las páginas. Ideal para hospedar contenido estático.

Es decir, una imagen siempre va a ser la misma, nunca va a cambiar en el 99% de los casos, por tanto es el candidato ideal para hospedarla en un CDN server. Adicionalmente el CDN tiene una capa intermedia de caché con un tiempo para vivir (TTL) de una a varias horas, quiere decir que los requests ni siquiera llegaran al servidor de CDN siempre, sino que se quedarán en el caché y de ahí se regresarán al browser. Un doble caching. Para aplicar esta primer solución, lo único que tenemos que hacer es redireccionar las llamadas de carga de contenido estático a un servidor de CDN, como se muestra en la siguiente imagen:

Y de esta forma, reducimos a un request el número de llamadas a nuestro servidor, y mantenemos el CDN con toda la carga de contenido estático. Esto va a reducir la carga de nuestro servidor de aplicaciones, sin embargo no significa que haya una ganancia considerable de tiempo de carga. Ya que ahora será otro servidor el que reciba toda la carga que tenía el sitio anterior.

Para ayudar a los servidores de CDN a hacer mejor su trabajo aplicamos un concepto que puede ser acompañado de otros elementos como la compresión de código (gzip), la ofuscación y la reducción de código entre otros.

Minificar en este caso, significa reducir a uno los requests de contenido estático de acuerdo a su tipo. Por ejemplo si tenemos 3 hojas de estilo, las podemos minificar a 1, si tenemos 20 archivos externos de JS, los podemos reducir a uno solo.

La herramienta que mejor se encarga de hacer este proceso es YUI Compressor (http://developer.yahoo.com/yui/compressor/), no sólo reduce todos los archivos CSS y JS en uno solo, sino que además reduce el tamaño del archivo eliminando comentarios, caracteres especiales (tabs, espacios, enters, etc) y ofuscando el código (Cambia el nombre de las variables de “miVariable” a “d”).

Ahora reducir aún más los requests a nivel de CDN es fácil con esta herramienta, así que en un ideal podríamos lograr 1 request al servidor de aplicaciones, 1 request al servidor de CDN para CSS y 1 request al servidor de CDN para JS. Nos queda el problema de las imágenes, que podemos mandar a un tercer CDN dedicado a trabajar con imágenes.

CSS Sprites

Para lograr el objetivo “ideal” de mantener en un request a todos nuestros servidores, vamos a reducir también las imágenes. Utilizando la técnica de CSS Sprites, vamos a construir un mapa de imágenes que estaremos mostrando en nuestro sitio en manera de máscaras. La imagen siguiente muestra un ejemplo de la aplicación de sprites a los iconos del header.

Claro que es un resultado ideal, dependiendo del diseño del sitio, los efectos, sombras y gradientes que se utilicen se podrá o no reducir a un request la carga de las imágenes. Sin embargo no siempre es posible, como resultado final la siguiente imagen muestra la reducción de requests del sitio a 5.

• Un request al servidor de aplicaciones
• Un request de CSS
• Tres requests de imágenes

Conclusión

Dependiendo del tamaño del sitio, la mayoría de estas técnicas siempre van a ser más rentables que el equivalente costo en hardware y tiempo para lograr un rendimiento mucho mejor que si no los aplicamos, dejando entonces esta inversión para el momento en el que realmente las visitas a nuestro sitio lo demanden.