Esto tiene algunas ventajas importantes, como que ahorra ancho de banda del servidor de la compañía y además hace que el propio sitio web cargue más rápido (ya que los navegadores hacen las peticiones a servidores distintos en paralelo). También optimiza el propio tráfico de Internet, porque si todo el mundo usa el mismo archivo del mismo servidor, la primera vez que el navegador lo solicita se guarda en caché, y en sucesivas peticiones no es necesario descargarlo.

A la hora de cargar bibliotecas podemos cargar la API de JavaScript de Google y desde ahí cargar mediante código JQuery (o la biblioteca que nos interese). Otra opción es cargar directamente el archivo desde el repositorio de Google:

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"></script>

Este enfoque es adecuado, pero tiene algunos problemas: ¿qué pasa si un día Google decide dejar de alojar el código? Esto no parece muy probable, pero ¿y si se cae un servidor de Google y nuestra página deja de funcionar? Vale que tampoco parece que vaya a ocurrir mañana. Pero hay una última posibilidad en la que no pensé en su día y que es bastante más posible que las anteriores: ¿y si un día le enseño el proyecto a un cliente en mi portátil (ejecutándolo en local) y no tengo conexión a Internet?

Y hay una opción que nos permite evitar este posible contratiempo. En el fondo, es tan sencillo como alojar la biblioteca en nuestro servidor y cargarla sólo si no se pudo cargar la de Google. Por ejemplo, así:

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"></script> <script type="text/javascript">// <![CDATA[
!window.jQuery && document.write('<script src="js/jquery-1.4.2.min.js" mce_src="js/jquery-1.4.2.min.js"><\/script>')
// ]]></script>

La primera línea se encarga de descargar el archivo de JQuery del servidor de Google. Y la segunda simplemente comprueba si se ha cargado correctamente, y si no, escribe en el documento el código necesario para que se cargue desde el servidor local.

De momento me estoy centrando en limitar las comprobaciones en la inclusión de archivos PHP, sustituyendo los require_once() por llamadas a require() convencionales (que resultan algo más rápidas al no tener que comprobar si el archivo ya ha sido incluido), en la corrección general del código, en la optimización de las consultas a la base de datos (verdadero cuello de botella de las aplicaciones web) y en la reducción del tamaño de las páginas.

Sobre esto último, algunas secciones del panel de control de Artefacto Server tenían código CSS o Javascript escrito directamente en el archivo PHP. Esto es un problema porque incrementa el tamaño de la página que se descarga al navegador, con lo cual el tiempo de carga es mayor. Ya solucionamos esto en gran medida en Artefacto Server 3.1, pero todavía quedaban algunos módulos con ciertas particularidades sin actualizar.

La ventaja de este enfoque es que el navegador guarda en la caché los archivos y eso siempre acelera la carga. No obstante, todavía se puede dar una vuelta de tuerca más, que consiste en comprimir el código Javascript o CSS, eliminando saltos de línea, espacios, etc. Adicionalmente, se puede cambiar el nombre de las funciones y variables y reducir el código todavía más. Para no tener que hacer este trabajo a mano hay algunas opciones interesantes, y la más popular parece ser JSMin, que además es libre. Hay una implementación en PHP, jsmin-php, con la que he estado trabajando estos días. He hecho la prueba con uno de los ficheros de funciones comunes y ha pasado de 3060 a 2476 bytes, lo cual nos arroja una tasa de compresión del 20%, que no está nada mal. Otro fichero Javascript del panel de control ha pasado de 3247 a 1754, lo cual supone una reducción de casi el 50%.

Hay que decir que todo esto no va a solucionarnos ningún problema por si solo, sino que tenemos que tomarlo como una acción más de un conjunto de medidas encaminadas a mejorar la rapidez general de la aplicación.

Vía | aNieto2k