El blog de Artefacto

Llevo todo el fin de semana arreglando el código de Artefacto Server, mejorando su legibilidad y tratando de mejorar su eficiencia todo lo que sea posible. El problema de las aplicaciones web es que en cuanto empiezan a crecer se multiplican las consultas a la base de datos, la inclusión de ficheros de PHP, la descarga de archivos de estilos o de Javascript… y al final pueden llegar a ser realmente pesadas.

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

Como paso previo a la creación de nuestro propio tema de Wordpress decidimos que lo mejor era traducir uno existente y después adaptarlo. Fruto de esa decisión, queremos publicar aquí la traducción que realizamos por si a alguien le sirve.

Hemos creado una sección de descargas donde iremos colgando poco a poco todo lo que podamos ir aportando a la comunidad. De momento ya se puede descargar el tema Journalist 1.9 traducido al español.

En Artefacto intentamos aportar un enfoque de calidad en todos nuestros proyectos, lo cual pasa ineludiblemente por utilizar estándares de codificación y por tener en cuenta la accesibilidad. Tradicionalmente, el uso de objetos Flash ha sido un inconveniente en este sentido, pero afortunadamente existen soluciones, la mayoría de ellas escritas en JavaScript, dirigidas a mejorar la integración de Flash en documentos XHTML.

Hasta hace unos meses, habíamos utilizado en nuestros proyectos el módulo Unobtrusive Flash Objects, que daba muy buenos resultados y que iba ya por su versión 3.22. Sin embargo, hace unos meses que apareció una revisión de este módulo, llamada SWFObject, que ya va por su versión 2.0, y que mejora en gran medida el uso de objetos Flash no obstructivo. En Google Code hay un wiki con mucha documentación sobre las opciones que permite este novedoso módulo.

En mi opinión resulta algo menos sencillo de usar que su predecesor, aunque los responsables del proyecto están en todo y han puesto a disposición de la comunidad un generador automático de código que simplifica en gran medida el trabajo.

La ventaja de todo esto es que se puede crear un contenido alternativo al Flash en la página, de manera que se mantenga la accesibilidad del sitio y de paso no perjudiquemos al posicionamiento. En nuestro último proyecto, una web realizada para la Sociedad de Montañeros Burgaleses (y que podéis ver en nuestro servidor de pruebas de momento) hemos seguido este enfoque. Así, en condiciones normales, el usuario vería el menú Flash:

Y si el navegador no soporta Flash o bien el usuario lo tiene desactivado, el contenido que se muestra es el siguiente:

Que aunque no es tan bonito como el Flash, sí que queda razonablemente bien para estar hecho sólo con texto y CSS, y además es totalmente accesible. La ventaja de este enfoque en el menú, es que por debajo del Flash sigue estando una lista XHTML con los enlaces, por lo que los buscadores los seguirán sin notar la diferencia. También hemos utilizado la misma estregia con la cabecera: en ausencia de Flash se carga una imagen que guarda la estética de la página.

Como digo, todo en una línea de compromiso con la accesibildad y las buenas prácticas de programación que esperamos ir extendiendo poco a poco a lo largo de toda nuestra estrategia de desarrollo web. Es un camino complicado pero vale la pena intentarlo.