Disminuir en lo posible el contenido devuelto a los visitantes para reducir el tiempo de descarga de una página es una solución obvia. Y precisamente por su obviedad es a menudo desestimada o simplemente olvidada por los responsables de los sitios web.

• Eliminar contenido innecesario
• Crear páginas específicas de contenido
• Paginar adecuadamente el contenido

Eliminar contenido innecesario

Debes preguntarte si todo el contenido (texto, enlaces, imágenes...) que muestras en cada página es realmente necesario, si aporta valor a los visitantes o si te ayudan a conseguir tus objetivos (cualesquiera que sean). Si hay partes de tu contenido que no cumplen ninguna de estas tres condiciones, deberías plantearte seriamente el eliminarlas.

En blogs la proliferación de distintos plugins y widgets para las distintas plataformas que existen han conseguido que muchos bloggers incluyan en su web contenidos innecesarios y poco funcionales. Esto es doblemente grave pues no sólo están reduciendo la velocidad de carga de sus páginas, sino que muy probablemente están aumentando además el tiempo de ejecución, ya que muchos de estos añadidos ejecutan consultas a la base de datos o realizan conexiones HTTP externas (normalmente a feeds).

El contenido irrelevante es fruto de una mala planificación. Todos los responsables de un sitio web deberían plantearse seriamente al menos una vez durante el proceso de planificación el tipo de datos que quieren que sus visitantes tengan accesibles.

Crear páginas específicas de contenido

Aunque hayas llegado a la conclusión de que cierto contenido es necesario, puede que no sea conveniente mostrarlo en todas las páginas de tu web, especialmente si tiene un tamaño considerable.

La solución es crear una página (sección) específica con ese contenido, teniendo así la oportunidad de tratarlo más en profundidad y la libertad de formatearlo más acordemente, algo que probablemente no podrías hacer en caso de incluirlo junto a otros datos. Como contrapartida encontramos la necesidad por parte de los visitantes de hacer un clic extra para acceder a ese contenido. Por lo tanto deberías evitar aplicar esta regla a contenido muy popular (visitado frecuentemente).

Como último paso necesitas hacer accesible esa página, normalmente incluyendo un enlace en algún tipo de menú o destacándola de la manera que creas más oportuna. En algunos casos será una buena idea incluir un extracto de ese contenido (los enlaces más relevantes, las últimas adiciones...) para hacer más accesible los datos más requeridos por los usuarios.

Paginar adecuadamente el contenido

Dividir grandes cantidades de contenido en distintas páginas es de vital importancia no sólo para reducir el tiempo de descarga sino para la correcta accesibilidad de dicho contenido. Y mientras que esta práctica es bastante común, rara vez se plantea si la paginación (el número de elementos mostrados por página) es la más adecuada.

Como ejemplo vamos a tomar WordPress, aunque otras plataformas de blogs tienen un comportamiento similar. Por defecto WordPress muestra 10 entradas en cada página de archivos (inicio, categorías, fechas, etc.). ¿Es 10 el número más adecuado de entradas por página?. Teniendo en cuenta que el 90% de los visitantes no van a leer más allá de la primera o segunda entrada, la respuesta parece evidente que es no. 10 puede ser un número adecuado si escribes entradas cortas (o muestras sólo estractos en vez de las entradas completas). Para entradas de extensión media (de 3 a 6 párrafos) un buen número puede ser 5. Y si escribes entradas de gran extensión, se puede llegar a reducir a 3. No es aconsejable mostrar sólo una o dos entradas por página con el fin de evitar problemas de duplicación en buscadores.

Afortunadamente en WordPress es posible cambiar este valor. Piensa detenidamente cual es el número más adecuado para tu blog e introdúcelo en Opciones > Lectura > Páginas del blog > Mostrar como máximo: XX entradas.

En peor situación nos encontramos con los comentarios. WordPress no incluye ningún tipo de paginación para los opiniones vertidas por los lectores de un blog. Sin embargo esta característica es absolutamente imprescindible en aquellos sitios que reciben una gran cantidad de comentarios (cientos o incluso miles), no sólo para evitar kilométricas páginas de cientos de KB, sino también porque las consultas a una base de datos que devuelven cientos o miles de resultados (como ocurriría en este caso) consumen una gran cantidad de recursos, sobrecargando el servidor y afectando de forma negativa al rendimiento (y por tanto a la velocidad) de todo el sitio web.

Para habilitar la paginación de comentarios necesitaremos de algún plugin como Paged Comments. Pero precisamente por ser un plugin no representa una solución perfecta, ya que por ejemplo repite el texto de la entrada en las distintas páginas de comentarios y su integración con el tema es mejorable.

1 Blog Theme incluye esta carecterística, basándose en Paged Comments pero con una mejor integración (variando títulos y contenido para las páginas de comentarios).

Esta entrada forma parte de la serie «Aumentar la velocidad de una página web en 7 pasos».

Aligerar el código nos va a permitir reducir el peso de una página web, y por tanto aumentar su velocidad de descarga, sin afectar su funcionalidad.

• Limpiar el código
• Comprimir el código

Limpiar el código

Podemos reducir el tamaño, no sólo del código HTML, sino también del CSS y del JavaScript (incluídos los archivos externos .css y .js) que contenga, siguiendo estas sencillas reglas:

• Eliminar el código superfluo, es decir aquél que no tiene ninguna incidencia en la página. El código superfluo es especialmente común en los sitios web que han sufrido rediseños o modificaciones, con estilos CSS que referencian clases o elementos que ya no existen o funciones JavaScript que ya no son utilizadas.
• Eliminar código redundante, es decir aquél que se encuentra duplicado y que por lo tanto obtiene los mismos resultados de diferentes formas. El código redundante es muy habitual en CSS, con elementos que están formateados mediante diferentes estilos.
• Eliminar los comentarios. Los comentarios son muy útiles cuando se está escribiendo el código, pero son totalmente innecesarios de cara a los usuarios, por lo que es una buena idea excluirlos, al menos en la versión pública de tu sitio web.
• Eliminar tabulaciones, retornos de carro y espacios innecesarios. Una vez que tengas tu código definitivo, puedes eliminar todos los caracteres innecesarios para reducir ligeramente el tamaño del archivo. Ya que el código quedará prácticamente ilegible, es conveniente mantener una versión del archivo sin «limpiar» de tal forma que puedas realizar fácilmente modificaciones sobre él (y volver a llevar a cabo este paso para reducir de nuevo su peso).

Hay herramientas que simplifican esta tarea, como HTML Code Cleaner para HTML, Clean CSS para archivos CSS o ShrinkSafe para archivos JavaScript.

Comprimir el código

El código de tu página web es básicamente texto, lo que significa que tiene un gran ratio de compresión. Un texto comprimido puede ver reducido su tamaño hasta en un 95%. La mayoría de los navegadores soportan la compresión en Gzip, lo que significa que las páginas se descargan comprimidas (con un tamaño mucho menor) y se descomprimen en el navegador para mostrarlas normalmente, aumentando considerablemente la velocidad de descarga.

Para que esto se lleve a cabo hace falta que las páginas se compriman desde el servidor. Si estás usando WordPress puedes habilitar la compresión con Gzip desde Opciones > Lectura > WordPress debería comprimir las entradas (gzip) si los navegadores lo requieren.

Si no usas WordPress, pero tu sitio web está basado en PHP, requerirás una simple línea de código para conseguir el mismo resultado:

<?php
if ( extension_loaded( "zlib" ) ) ob_start( "ob_gzhandler" );
?>

Este código comprueba si la libreria gzip está cargada, y en caso afirmativo usa un buffer interno que almacenará la salida para devolverla finalmente comprimida. Debes colocar esta línea lo antes posible dentro de tu código, antes de que se haya devuelto ningún tipo de contenido. La llamada de retorno ob_gzhandler se encarga de comprobar si el cliente (el navegador) soporta la compresión Gzip, y en caso contrario devuelve la salida sin comprimir.

Con este sencillo código puedes enviar comprimida cualquier página de HTML. Pero podemos ir más allá y comprimir además los archivos CSS y JavaScript externos que use tu web. Estos archivos tienen las extensiones .css y .js, y a no ser que cambies la configuración del servidor, no soportan PHP. Por lo tanto el primer paso será cambiar la extensión de estos archivos a .php. Por ejemplo, de estilo.css a estilo.php o de javascript.js a javascript.php. Esto presenta dos graves, aunque salvables, inconvenientes:

• Los archivos .css y .js son cacheables por el navegador (por lo que sólo son descargados la primera vez y su carga es automática en sucesivas ocasiones), mientras que los .php no.
• Algunos navegadores no interpretan los archivos .php como CSS o JavaScript independientemente de que sean referenciados mediante las etiquetas<script type=»text/javascript»...> o link rel=»stylesheet» type=»text/css»...>.

Para solventar esto, necesitaremos añadir unas líneas más al código anterior. Por ejemplo, en el archivo CSS:

<?php
@header( "content-type: text/css" );
@header( "Cache-control: max-age=".(12*60*60).", must-revalidate" );
@header( "Expires: ".gmdate("D, d M Y H:i:s", time()+12*60*60)." GMT" );
if ( extension_loaded( "zlib" ) ) ob_start("ob_gzhandler" );
?>
...Aquí el CSS...

Análogamente, en el archivo JavaScript:

<?php
@header( "content-type: text/javascript" );
@header( "Cache-control: max-age=".(12*60*60).", must-revalidate" );
@header( "Expires: ".gmdate("D, d M Y H:i:s", time()+12*60*60)." GMT" );
if ( extension_loaded( "zlib" ) ) ob_start( "ob_gzhandler" );
?>
...Aquí el JavaScript...

En los códigos anteriores se envía un encabezado HTTP con el Content-type correcto para que el navegador lo trate como un archivo .css o .js corriente. Los encabezados Cache-control y Expires indican al navegador que debe cachear el archivo durante 12 horas (12 por 60 por 60 segundos). Puedes cambiar el 12 a cualquier otro valor. La línea que habilita la compresión con Gzip es la misma de antes.

Gracias a este simple método conseguirás reducir sustancialmente el tiempo de descarga de tu página web. Como contrapartida tu servidor consumirá más CPU al tener que realizar los cálculos para comprimir el texto. Aunque los efectos de la compresión Gzip sobre el servidor no están del todo claros, ya que este método también tiene como efecto el que haya menos conexiones abiertas (al devolver la respuesta más rápidamente), aligerando por tanto la carga del servidor. Que en conjunto la compresión sea beneficiosa o perjudicial para el servidor seguramente dependerá de cada sitio web.

Esta entrada forma parte de la serie «Aumentar la velocidad de una página web en 7 pasos».

Los siguientes métodos no van a mejorar la velocidad efectiva de tu web, ya que ésta va a tardar en cargar todos sus elementos más o menos el mismo tiempo, sin embargo va a mejorar la velocidad percibida, haciendo básicamente que el contenido relevante se muestre antes a tus visitantes. Aumentar la velocidad de carga aparente es tan importante como aumentar la real, ya que los usuarios de un sitio web no cronometran tiempos de carga, sino que intentan acceder a la información que buscan lo antes posible.

• Deshacerse de las tablas.
• Colocar el contenido al principio.
• Colocar el JavaScript al final.
• Especificar el ancho y alto de las imágenes.

Deshacerse de las tablas

Aunque afortunadamente la maquetación con tablas (<table>...</table> en HTML) es algo cada vez más infrecuente de ver, aún hay sitios web que se resisten al paso del tiempo y basan su diseño en arcaicas filas y columnas. Aunque las tablas en sí no tienen nada de malo (de hecho son muy útiles para presentar series de datos), los diseños basados enteramente en estos elementos presentan un grave inconveniente: algunos navegadores como Internet Explorer necesitan descargar enteramente una tabla antes de mostrar su contenido. Y pese a quien le pese el Explorer es todavía el navegador más usado. Esto quiere decir que si toda tu página está encerrada en tablas, la mayoría de tus visitantes necesitarán descargarse todo el código por completo antes de empezar a ver cualquier tipo de contenido.

Solucionar este inconveniente es algo relativamente sencillo y consiste en migrar el diseño de la página a CSS. Las páginas cuya disposición se basa en estilos CSS muestran sus distintos elementos tan pronto como llegan al navegador, realizándose por tanto la carga de una manera totalmente fluida, lo que reduce el tiempo de espera para los visitantes.

CSS («Cascading Style Sheets», es decir, hojas de estilo en cascada) es lo suficientemente flexible como para servir de soporte a cualquier tipo de diseño. Si estás empezando con CSS puede que te interese visitar esta guía breve o, aún más sencillo, descargarte una de estas plantillas básicas sobre las que basar tu diseño.

Colocar el contenido al principio

Ya que, tras el punto anterior, el contenido de tu web se va a ir mostrando tan pronto como se va cargando, es interesante colocar el contenido relevante lo antes posible. Y por «antes» no me refiero a la disposición visual sino a su posición dentro del código HTML de la página, que es lo que va a determinar el orden de carga.

Normalmente la acción a realizar en este aspecto es colocar el código de la barra lateral (sidebar, en la que normalmente se situán todos los enlaces a secciones, categorías, etc.) después del contenido principal, aunque dependiendo del diseño puede que haya más elementos que puedan ser retrasados en su orden aparición. El auge de las barras laterales alineadas a la derecha del contenido hace que este paso normalmente no sea necesario, aunque aún hay muchos diseños que muestran el sidebar en la izquierda y cuyo código también aparece antes del contenido.

Alinear la barra lateral a la izquierda no es un problema como tal; de hecho yo soy partidario de este tipo de disposición ya que los usuarios están tradicionalmente acostumbrados a ella (aunque esa es otra historia y será contada en otro momento). Lo que sucede es que aún hay diseñadores que no saben que es posible colocar el código de la barra «después» aunque visualmente aparezca «antes». Con CSS esto es muy sencillo gracias al atributo float que hace referencia a la alineación de los elementos. Por ejemplo con el siguiente código la barra lateral alineada a la izquierda se cargará después del contenido:

<div style="float: right; width: 70%">
...Aquí el contenido...
</div>
<div style="float: left; width: 30%">
... Aquí la barra lateral...
</div>

En blogs el uso de este método junto a la descarga por partes de la página con flush() es especialmente importante ya que los sidebars suelen hacer uso intensivo de consultas a la base de datos, y por tanto su tiempo de ejecución es mayor.

También en blogs es interesante incluir los comentarios en un bloque diferente al del resto de contenido y al final de la página, ya que las entradas con muchos comentarios pueden retrasar sustancialmente la carga de otros elementos (normalmente la barra lateral).

Colocar el JavaScript al final

Las referencias a los archivos externos de JavaScript (.js) se suelen colocar en el encabezado (entre las etiquetas <head></head>) por simple costumbre. Sin embargo muchos de estos archivos ejecutan su código cuando la página ya se ha cargado, mediante llamadas del tipo document.onload = (...). En este caso desde el punto de vista del código es indiferente que ese archivo se cargue antes o después del contenido. Por lo tanto colocándolo al final de la página, justo antes de la etiqueta de cierre </body>, evitaremos que la descarga de ese archivo retrase la aparición del contenido. El HTML quedaría entonces así:

...
<script type="text/javascript" src="archivo.js"></script>
</body>

Por supuesto si el archivo contiene variables o funciones que son utilizadas en tiempo de carga, retrasar su ejecución puede llevar a errores o comportamientos no deseados, así que hay que tener cuidado en este sentido.

Un ejemplo típico de llamadas a archivos JavaScript que se pueden situar al final de la página son los códigos de servicios de estadísticas, tracking, etc. Por ejemplo Google Analytics proporciona un código para el seguimiento de los visitantes que recomienda colocar al comienzo de la página. Mientras que esto no suele representar ningún problema, en ocasiones los servidores de Analytics resultan especialmente lentos, retrasando la carga de las páginas que incluyen su script. Colocando el código dado antes de la etiqueta </body> evitaremos este inconveniente, aunque hay que tener en cuenta que esto puede reducir el número de visitantes reportados por Analytics, ya que en ocasiones las páginas no se llegan a cargar por completo y el código de este servicio no llega a ser ejecutado.

Especificar el ancho y alto de las imágenes

De los aspectos que estamos tratando éste es el que es descuidado con mayor frecuencia, por la creencia generalizada de que no afecta a la velocidad de carga de una página. Y en cierta forma es cierto, ya que una imagen se descarga igual de rápido tanto si se especifica su tamaño como si no. Sin embargo no establecer el ancho y alto de las imágenes (atributos width y height) va a afectar de manera negativa la velocidad de carga aparente.

Cuando no se especifican los atributos de tamaño de una imagen, el navegador reserva inicialmente para ella cierto espacio que rara vez coincide con sus dimensiones reales. Cuando el navegador empieza a cargar esa imagen, le asigna el tamaño adecuado, «descolocando» normalmente los elementos a su alrededor. Ésto hace que el contenido no esté completamente accesible (estático) hasta que todas las imágenes han comenzado a cargar.

Sin embargo, especificando el ancho y el alto de las imágenes, una vez cargado el código de la página todos los elementos se mostrarán ya en su ubicación definitiva, independientemente de cuándo se carguen las imágenes. Esto proyecta la sensación de que la página se ha cargado más rápidamente.

Uno de los grandes culpables de que en muchos de los sitios no se declaren los atributos de tamaño es WordPress. Por alguna extraña razón este CMS no incluye por defecto las dimensiones de las imágenes al añadirlas al editor desde el gestor de archivos (botón «Enviar al editor»). Para resolver este problema en WordPress tienes varias opciones:

• Incluir directamente los atributos en el código de la imagen (<img src=»...» width=»XX» height=»YY» />).
• Especificar el alto y el ancho en el menú «Insertar/editar imagen».
• Usar este plugin que he escrito y que añade automáticamente los atributos de tamaño de las imágenes (siempre que estén alojadas en tu propio blog) al guardar las entradas. Descomprime el archivo, súbelo a la carpeta wp-content/plugins y actívalo desde el panel de WordPress. El plugin sólo añade los atributos si éstos no existen, o calcula uno de ellos si éste falta y el otro está especificado. Además realiza las operaciones en el panel de control, no al mostrar las entradas en la parte pública, por lo que no afecta al tiempo de ejecución del blog. 1 Blog Theme incluye automáticamente esta característica, así que si lo estás usando no hace falta que instales el plugin.

Esta entrada forma parte de la serie «Aumentar la velocidad de una página web en 7 pasos».

Por archivos externos vamos a entender aquellos elementos que se se cargan junto a una página pero que no se incluyen en ella, es decir, son llamados desde una url diferente. Los archivos externos más comunes son imágenes, hojas de estilo CSS (.css) y archivos JavaScript (.js).

Mientras que normalmente no vamos a poder reducir el número de imágenes necesarias para mostrar nuestra web sin alterar el diseño (aunque si se puede hacer algo al respecto mejor que mejor), es probable que sí podamos hacer algo con las hojas de estilo CSS y los archivos JavaScript. Los archivos .css, junto con los .js que se cargan antes del contenido, tienen especial relevancia ya que los navegadores necesitan descargarlos por completo antes de mostrar la página. Y esto puede representar un problema si tenemos en cuenta el tiempo de respuesta del servidor.

La importancia del tiempo de respuesta

Todos los servidores tienen un tiempo de respuesta, que es el que transcurre desde que recibe una petición hasta que empieza a devolver datos. A este tiempo de respuesta hay que añadirle el que tarda el cliente en realizar dicha petición (no en descargar el archivo, sino simplemente en «solicitar» su descarga), lo cual depende de su velocidad de conexión. Esos tiempos normalmente suman un total de varias décimas de segundo. Décimas de retraso en la carga de la página que se multiplican por cada uno de estos archivos.

Imaginando un tiempo de respuesta total de 2 décimas de segundo (que es algo bastante corriente) la diferencia entre tener, por ejemplo, 6 archivos de JavaScript externos de 10Kb y un único archivo de 60 Kb es de ¡un segundo!. Un segundo de más en la carga de la página y, si dichos archivos se cargan previamente al contenido, un segundo de más en el que tus visitantes estarán contemplando una bonita página en blanco.

Si tienes curiosidad por saber el tiempo de respuesta de tu servidor, puedes hacer un ping desde la linea de comandos de tu sistema operativo (ping www.dominio.com) o usar esta herramienta online.

La solución al problema

La solución a esta situación es bien sencilla y consiste en limitar en lo posible el número de archivos externos que se encuentran en la página, con especial atención a aquellos que se encuentran antes del contenido (normalmente entre las etiquetas <head></head>).

Esto no representa mayor complicación ya que los .css y los .js son simples archivos de texto, y reducir su número es tan sencillo como copiar y pegar su contenido en un único archivo (uno para el CSS y otro para el JavaScript, por supuesto). Tan sólo hay que tomar la precaución de conservar el orden del código de los archivos, para evitar una superposición de estilos equivocada en CSS y la llamada a funciones o variables no definidas en JavaScript.

Para aquellos poco dados al código HTML, las hojas de estilo CSS se referencian de esta forma:

<link rel="stylesheet" type="text/css" href="archivo.css" />

O bien de ésta:

<style type="text/css">
@import url(archivo.css);
</style>

Y los archivos externos de JavaScript son llamados así:

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

Estos códigos se sitúan normalmente entre las etiquetas de encabezado (<head></head>), y si usas WordPress probablemente encontrarás esas etiquetas en el archivo header.php del tema que estés usando.

Las excepciones

Hay dos casos en los que no merece la pena, e incluso es contraproducente, aplicar esta medida:

• Las hojas de estilo CSS que están definidas para distintos medios (pantalla, impresión...), ya que normalmente el navegador sólo pedirá la versión para pantalla (media=screen).
• Los archivos de gran tamaño que no se incluyen siempre de forma conjunta. Si tienes una gran cantidad de código dividido en distintos archivos, y éstos son llamados desde distintas páginas dentro de tu web, no merece la pena obligar a los visitantes a decargarse un único archivo de mayor tamaño, ya que el tiempo de descarga adicional seguramente superará al ahorro que supone en tiempo de respuesta.

Además, puede que a alguien se le ocurra la brillante idea de ahorrarse directamente la conexión a esos archivos e incluir todo el código CSS y JavaScript en la propia página. Evidentemente esto es una mala idea: esos archivos externos son cacheados en la mayoría de las ocasiones por los navegadores, por lo que cuando alguien visite una página de tu web, se ahorrará la descarga de ese código en las sucesivas páginas a las que acceda.

Esta entrada forma parte de la serie «Aumentar la velocidad de una página web en 7 pasos».

Empezamos esta serie de entradas con la función flush() porque es un método sencillo de implementar, porque tiene un gran rendimiento y porque rara vez se usa o se habla de él. En años y años de escribir código, y por lo tanto de estudiar el código escrito por otras personas (scripts, temas para WordPress, etc.), en raras ocasiones he visto usar esta función, y no alcanzo a comprender por qué. Yo siempre la he utilizado en las webs que he desarrollado, con excelentes resultados.

Flush() es una función de PHP que vacía el buffer de salida y trata de enviar todos los datos «escritos» (echo, print, etc.) hasta ese momento al navegador del cliente. Normalmente un script PHP se ejecuta en su conjunto y sólo al final devuelve los datos (código HTML, XML...) al cliente. Flush() evita esto permitiendo la ejecución del script «por partes».

¿En qué te puede ayudar esto?. Muy sencillo. Colocando llamadas a esta función justo antes de bloques cuya ejecución no sea «instantánea» (consultas a bases de datos, conexiones HTTP externas, etc.) conseguirás que tus visitantes empiecen a cargar las páginas antes, reduciendo el tiempo de respuesta e incrementando la velocidad de carga aparente.

Implementación

El uso de esta función es muy sencillo y está al alcance de cualquiera. Tan sólo hay que hacer una llamada a flush() dentro de las etiquetas de PHP y listo. Como puedes observar, no hace falta ser un experto para escribir el código:

<?php
flush();
?>

Si quieres ver a flush() en acción, y comprender de una forma más gráfica cómo funciona, puedes hacer la prueba de incluir éste código hacia la mitad de una página PHP (cuando ya se haya devuelto código que se pueda ver a través del navegador):

<?php
flush();
sleep(5);
?>

Esto hará que se devuelvan todos los datos almacenados hasta ese momento para que después la función sleep() haga detenerse al script durante 5 segundos, por lo que verás exactamente en qué momento se ejecuta esa parte del código. Después de ese tiempo el resto de la página se cargará normalmente. Sin la llamada a flush() (prueba a eliminar esa linea) la página comenzaría a cargarse después de esos segundos (más el tiempo de ejecución normal del script). La llamada a sleep sólo sirve como ejemplo, no se te ocurra incluirla definitivamente en tu página.

Flush() en WordPress

Para la aplicación práctica vamos a tomar WordPress como ejemplo. Este gestor de contenido usa muchas funciones que ejecutan consultas a la base de datos en la que se almacena la información de las entradas, comentarios, categorías, etc. Dependiendo de cómo estén formadas, la calidad de tu servidor, la carga que esté soportando en ese momento, etc. cada una de esas consultas puede tardar un tiempo sustancial en ejecutarse.

Uses el tema (plantilla, o como quieras llamarlo) que uses, éste realiza consultas a la base de datos bien por sí mismo o bien mediante las funciones predefinidas de WordPress. Colocando una línea con flush() antes de que esas funciones sean llamadas evitarás que una consulta lenta retrase la carga de la página. Para que te hagas una idea, y siempre dependiendo del servidor, un tema puede llegar a tardar en ejecutarse desde unas pocas décimas a varios segundos. Sin embargo, antes de que se ejecute el código del tema, es decir, en el momento en que se dispone de los datos suficientes como para empezar a devolver código al cliente, se han llevado a cabo unas operaciones básicas de WordPress que tardan en efectuarse en torno a una décima de segundo (puede que más dependiendo de los plugins que tengas activos). Colocando un flush después del primer bloque de contenido estático del tema (encabezado, etc), la carga de la página empezaría justo en ese instante. Que una página empiece a responder en una décima de segundo en vez de en barios segundos evidentemente representa una notable mejora.

Para habilitar la carga por partes de un tema para WordPress, sólo tienes que editar los archivos .php de ese tema (que se encuentran en wp-content/themes/nombredeltema) y modificar el código justo antes de las llamadas a las funciones que realicen consultas a la base de datos. Típicamente en WordPress estas funciones son:

• wp_get_archives()
• wp_list_pages()
• wp_list_cats()
• wp_list_categories()
• wp_list_bookmarks()
• get_links_list
• get_links()
• wp_tag_cloud()
• get_posts()
• comments_template()

Por supuesto hay más, y de hecho algunas funciones pueden realizar consultas o no dependiendo de si los elementos a los que referencian están almacenados o no en la caché interna. Además, si el tema realiza consultas que no están contempladas en las funciones básicas de WordPress, muy probablemente use alguna de estas funciones de la clase $wpdb:

• $wpdb->query()
• $wpdb->get_var()
• $wpdb->get_row()
• $wpdb->get_col()
• $wpdb->get_results()

Para trabajar sobre un tema existente y que todo el mundo pueda consultar, vamos a implementar este método en el tema por defecto de WordPress (wp-content/themes/default). Primero podemos modificar el archivo sidebar.php de esta manera:

...
<?php
flush();
wp_list_pages( 'title_li=<h2>Pages</h2>' );
?>
<li><h2>Archives</h2>
<ul>
<?php
flush();
wp_get_archives( 'type=monthly' );
?>
</ul>
</li>
<?php
flush();
wp_list_categories( 'show_count=1&title_li=<h2>Categories</h2>' );
?>
<?php /* If this is the frontpage */ if ( is_home() || is_page() ) {
   flush();
   wp_list_bookmarks();
   ?>
   ...

Los cambios anteriores harán que la página empiece a cargar tras la primera llamada a flush() (justo después de que se hayan devuelto las entradas), y que esos bloques que pertenecen a la barra lateral del blog se devuelvan paulatinamente según se van finalizando las consultas (ésto no suele ser apreciable).

Sólo nos faltaría modificar de la misma forma los archivos single.php y attachment.php antes de la llamada a comments_template(), que es la que se encarga de extraer de la base de datos y mostrar los comentarios para cada entrada:

<?php
flush();
comments_template();
?>

Por supuesto modificar cualquier otro tema para WordPress se hace de forma análoga (comprueba todos los archivos en busca de este tipo de funciones, no sólo los mencionados) y no debería suponer ningún problema. Haciendo algo de autobombo, 1 Blog Theme, el tema que usamos en la red 1Blogr (incluyendo este mismo blog) hace uso de flush() antes de cada consulta a la base de datos, por lo que tiene una carga muy liviana.

Cuándo flush() no funciona

En algunos casos flush() no cumplirá su labor, aunque de ningún modo devolverá un error. Por ejemplo, si tienes habilitada la compresión por Gzip en WordPress (Opciones > Lectura > WordPress debería comprimir las entradas (gzip) si los navegadores lo requieren), flush() no vaciará el buffer, ya que la salida se reserva para enviarla comprimida al final de la ejecución del script.

Flush() en otros lenguajes

Por supuesto la función flush(), o alguna análoga con los mismos resultados, estará disponible en la mayoría de lenguajes de programación de servidor. Por ejemplo en ASP (Active Server Pages) el equivalente es el método Response.Flush.

Esta entrada forma parte de la serie «Aumentar la velocidad de una página web en 7 pasos».