¿Estás referenciando jQuery de forma correcta en tus aplicaciones?

¿Cuántos de ustedes trabajan en proyectos web? ¿Cuántos utilizan la biblioteca jQuery? Si la respuesta a la primera pregunta es afirmativa, hay grandes posibilidades que la segunda respuesta lo sea también. jQuery es uno de los frameworks más utilizados hoy en día - por méritos bien ganados según mi opinión -, así que en una gran parte de los sitios en los que inspeccionamos el código podremos encontrar alguna variación de la siguiente referencia:

<script type="text/javascript" src="jquery.min.js" />

La instrucción indica que la biblioteca se va a cargar del directorio local donde se encuentra la página que estamos visitando (o de un directorio del sitio en caso de que esté especificado de esa forma). Y claro está que funciona bien, pero... hay un pequeño secreto: no funciona todo lo bien que pudiera.

¿Cuál es el punto? Pues que la biblioteca está siendo servida por el propio servidor web de la aplicación, y  estamos perdiendo una oportunidad dorada de quitarnos este recurso de encima y ganar unos cuantos milisegundos de velocidad en nuestra página. Hay alguien más que ya está sirviendo jQuery... y lo ha hecho público para que todos lo aprovechemos... y es nada más y nada menos que Google.

Y voy un poquito más allá para aquellos que utilizan otras bibliotecas diferentes a jQuery: Google sirve a través de su CDN (Content Distribution Network) frameworks como MooTools, Prototype, YUI, Dojo, Ext Core, entre otros. El listado completo pueden verlo en la página de Google Libraries API. Todo esto allí, listo para ser utilizado y nosotros mirando hacia otra parte. ¡Qué desperdicio!

Ahora bien, si ustedes son tan "cabeza dura" como yo, se preguntarán qué ventajas tiene utilizar las versiones que provee Google en vez de incluir los ficheros de forma local en nuestras aplicaciones, y la respuesta podemos encontrarla si investigamos un poquito qué es un CDN. Cómo todos no tiene tiempo para botar, voy a evitarles la búsqueda y les resumo en tres puntos cuáles son las ventajas de utilizar las bibliotecas del CDN en vez de nuestra propia copia:

1. ¿Quién dice que todos los usuarios necesitan bajar la biblioteca?

Así mismo como lo leen. Siempre que incluyamos la biblioteca en nuestro servidor, todos los usuarios tendrán que bajar una copia del fichero cuando se carga por primera vez nuestro sitio. Sin embargo, cuando usamos la biblioteca del CDN, puede que muchos usuarios no tengan que descargarla ni siquiera la primera vez.

Si accedemos a dos sitios diferentes donde cada uno incluye una copia de la biblioteca, los navegadores ignorarán el hecho de que ya antes bajaron el mismo fichero, así que es posible que en nuestro caché local de Internet tengamos unas cuántas copias de jQuery (para seguir con el mismo ejemplo). Sin embargo, si los mismos dos sitios incluyen solo una referencia al jQuery almacenado en el CDN, solamente el primero tendrá que descargarlo, ya que el segundo utilizará la copia del fichero en el caché local. La explicación está en que el fichero proviene de la misma URL, así que el navegador es lo suficientemente inteligente para referenciarlo localmente en vez de perder tiempo descargándolo otra vez.

La buena noticia es que muchos de los sitios más visitados en Internet (incluyendo los sitios del propio Google) ya utilizan las bibliotecas del CDN, así que si nosotros hacemos lo mismo hay grandes posibilidades que los usuarios de nuestras aplicaciones no tengan que descargar el fichero para nada, y en vez de ello, una copia almacenada en su caché local sea utilizada.

2. Si eliminamos una solicitud, la aplicación entera saldrá beneficiada

No solo vamos a ahorrarnos descargar la biblioteca de la red, sino que hay otra ventaja relacionada con el número de conexiones abiertas con nuestro servidor. La cantidad de conexiones simultáneas permitidas en un servidor web varía, pero independientemente de cuál sea la cantidad (¡en muchos casos son solo dos!), el quitarnos un recurso de nuestra lista libera una de estas conexiones para otros elementos de nuestro sitio (imágenes, otras bibliotecas, ficheros de estilos, etc). Así que más recursos serán cargados a la misma vez provocando que nuestra página termine de cargar mucho antes.

3. Y si tenemos que descargarla, pues al menos que sea más rápido

Y bueno, no en todos los casos tendremos la biblioteca en el caché local del usuario, así que el navegador tendrá que hacer su trabajo y descargar el fichero, pero... ya que estamos hablando de un CDN, la descarga será potencialmente más rápida que si se hiciera desde nuestro servidor.

Una de las características de los CDN es que distribuyen el contenido en varios servidores localizados en diferentes puntos geográficos. En dependencia de la ubicación de la solicitud, el servidor más cercano será el encargado de servir el contenido, lo que provocará una notable mejora en la velocidad de transferencia. Esto quiere decir que si un usuario en China visita nuestro sitio (y no tengo idea si el CDN de Google tiene servidores en China), las bibliotecas serán descargadas desde un servidor mucho más cercano a su ubicación por lo que el tiempo de descarga será mucho menor.

Y al final de cuentas, ¿cómo uso el dichoso CDN?

Pues super-duper simple. El primer paso es borrar la biblioteca (o las bibliotecas, si estamos usando más de una) de nuestro sitio local. Acto seguido, actualizamos las referencias para que sean descargadas del CDN de Google:

<script type="text/javascript" src="//ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.min.js" />

A los curiosos que se pregunten de dónde salió el URL sin protocolo que se está referenciando, esto no es más que una dirección que funcionará de la misma forma para sitios sobre HTTP o sitios con SSL (HTTPS). Para más información, pueden ver la explicación completa en la sección 4.2 del RFC 3986. Es una buena práctica referenciar las bibliotecas de esta manera y así no tenemos luego que preocuparnos en caso que queramos montar nuestra aplicación con SSL. De todos modos, para el que no esté interesado, puede utilizarse el protocolo (http:// o https://) como en cualquier otra URL a la que estamos acostumbrados.

Para terminar

A pesar que la explicación ha sido enorme, la solución es bien simple y bien vale la pena comenzarla a implementar en nuestras aplicaciones (e incluso cambiar las que ya tenemos). Aunque muchos no crean que las ganancias en velocidad serán significativas, yo les aseguro que no todos navegan hoy en día con conexiones super veloces capaces de opacar unos pocos milisegundos. Por otra parte, el acceso a través de dispositivos móviles (EDGE, 3G) sigue siendo lento, y optimizar nuestras páginas es la mejor manera para que los usuarios reciban el contenido de la mejor forma posible.