Es una situación en la que cualquier desarrollador se encuentra muy a menudo, por no decir en cada proyecto: la web del cliente, elaborada con la última tecnología, cargada de plugins y complementos, con un diseño hipervistoso, ya está finalmente en el aire. Tras la ilusión inicial después de tanto esfuerzo llega la decepción: «Esta web va muy lenta». Pero ya está publicada y no queda más opción que buscar alguna solución para mejorar las prestaciones lo más rápidamente posible antes de que se lance la primera campaña. ¿Qué haremos?

En primer lugar tengamos claro que no se trata de magia ni ocultismo. Es tecnología pura y dura. Todo problema tiene unas causas muy bien determinadas y sólo es cuestión de dar con ellas. Hagamos ahora un pequeño repaso de todos los factores que influyen en las prestaciones de una web. Lo podemos representar con la siguiente fórmula (nada científica, sólo a efectos de ilustración):

Vamos a repasar estos factores uno por uno.

Prestaciones

Vamos a llamar así a la percepción del usuario sobre la usabilidad de la web. El concepto de «rápido» o «lento» es bastante subjetivo y está claro que lo que para algunas personas está muy bien para otras es insuficiente.

Lo más correcto sería evaluar el tiempo de carga en segundos utilizando cualquier de las muchas herramientas disponibles, desde las herramientas web de Chrome hasta otras como GTMetrix o Google Pagespeed y establecer unos criterios cuantificables comparando con sitios similares, pero en última instancia si el cliente dice que la web va lenta… pues es que va lenta. No lo discutamos.

Recursos de hardware

Es algo bastante obvio. A fin de cuentas, un sitio web no es más que una aplicación informática que genera código HTML (y sirve todos sus elementos auxiliares) para ser renderizado en el navegador del usuario. Y como tal, la velocidad de ejecución depende de los recursos de que disponga. Evidentemente, no dará las mismas prestaciones un servidor único de 1 core y 1GB de memoria que un cluster de varias máquinas dedicadas y especializadas en diferentes “roles” como servidores de base de datos, servidores web, proxys… Ni por supuesto, tendrán el mismo coste. También debemos prestar atención a las diversas modalidades que los proveedores de hosting ofrecen: desde los alojamientos compartidos (económicos, pero muy limitados en cuanto a prestaciones y posibilidades de configuración) hasta servidores privados virtuales (VPS) o físicos. Pero hay un apartado muy importante que veremos a continuación y suele ser completamente ignorado. Se trata de la…

…optimización

En la mayoría de los casos no se presta mucha atención a este aspecto. Lo que prima es la rapidez de despliegue y se dejan los servidores en su configuración por defecto, que dista mucho de ser la óptima. En caso de que se quede corto simplemente se opta por «meter más máquina» aunque resulte considerablemente más caro a largo o incluso medio plazo.

Y sin embargo, con unos pequeños retoques -que tienen que ser realizados por una mano experta- se podrían aumentar las prestaciones en casi un orden de magnitud. Hay mejoras que se realizan a nivel de servidor (configuración de apache, sistema de archivos, MySQL, red) y otras a nivel de aplicación (WordPress, Drupal, u otro CMS). Estas últimas suelen pasar por la instalación de un módulo de caché; los hay muy variados y en general, los más eficientes son más complicados de configurar (para WordPress, mi favorito es el W3 Total Cache). Hay que tener cuidado además de que no interfieran con otros plugins.

Tráfico

Al contrario de lo que ocurre en medios como la televisión o la radio, en los que una mayor audiencia no supone una mayor necesidad de potencia, en Internet cada usuario consume una cierta cantidad de recursos. Con un determinado hardware no podremos atender satisfactoriamente más que a “n” visitantes simultáneos; eso no tiene vuelta de hoja.

El problema viene agravado por la gran variabilidad de la audiencia en la web. Aparte de las fluctuaciones cíclicas diarias, que suponen un contraste de 10 a 1 entre periodos valle y pico, siempre puede ocurrir que un post se vuelva viral y en cuestión de horas un blog desconocido comience a tener miles de visitas que colapsen su servidor. Este es el problema de más difícil solución, ya que no resulta económicamente viable disponer de una infraestructura dimensionada para un tráfico masivo que se dará un par de veces al año.

Pero por otra parte, es precisamente en esos “picos” cuando el cliente más necesita la disponibilidad de la web al coincidir normalmente con campañas de ventas o publicidad en otros medios. Hay arquitecturas «elásticas» como la de Amazon Web Services que permiten lanzar instancias de servidores bajo demanda pagando por la potencia que se utilice, pero la configuración inicial es compleja y normalmente sólo es rentable para webs de alta utilización.

Complejidad

Los sistemas actuales de CMS -y tengo principalmente en mente a WordPress- son muy, pero que muy extensibles. Puede que demasiado. Disponen de una extensa biblioteca de plugins y temas (la mayoría gratuitos) para cualquier función que se pueda imaginar. Con sólo saber subir archivos por FTP es suficiente para ponerlos en marcha.

Pero cada complemento que instalamos introduce una serie de hooks y llamadas que ralentizan el funcionamiento de la web, incluso en las páginas que no lo utilizan. Además, la probabilidad de interferencias e incompatibilidades entre ellos aumenta exponencialmente con su número. Muchas extensiones y temas superan en líneas de código (pero no en calidad) al propio “core” de WordPress.

En el desarrollo de software, lo que más cuenta últimamente es el time to market y eso hace que nos encontremos con muchos casos de programación apresurada, muy poco optimizada, mal estructurada y difícil de mantener. Lo que en la jerga se suele llamar código spaghetti. La forma en que esté programada una aplicación puede tener efectos dramáticos en el tiempo de ejecución. Por eso es conveniente echar un ojo al código fuente (esa es una de las maravillas del open source) y comprobar las prestaciones antes de decidirnos a instalar cualquier complemento o tema. Afortunadamente hay tal cantidad de ellos que para cualquier función podemos encontrar docenas. Lo difícil es elegir.

Herramientas

Existen múltiples utilidades para poner a punto nuestra web. Ahora bien, siempre es necesario tener «ojo clínico» para saber interpretar los resultados. Existe la tendencia a suponer que si algo aparece en rojo en el informe, es que está mal.

Puede que sí, o puede que no. O puede que sea sólo un desajuste menor que nos hace perder algunos milisegundos, pero para corregirlo sería necesario reescribir todo WordPress. De hecho, si aplicamos estas herramientas a webs de primera línea también «cantan» bastantes imperfecciones y les dan una calificación regular.

Por otra parte, hay que tener en cuenta que influyen muchos factores que no están bajo nuestro control: las prestaciones del operador de Internet que utilizamos, los elementos externos (p.ej. widgets de Twitter, Facebook…) incorporados, saturación en la red o “blackouts” puntuales, etc… En otro post incluiré un listado de las utilidades y recursos que he encontrado de más ayuda para el diagnóstico y mejora de sitios web aunque la lista no será exhaustiva: tengo casi cien marcadores en la sección de «utilidades web», pero hay una docena que uso casi a diario y considero verdaderamente interesantes.