Page caching o cacheo de páginas (WPO)

Publicado por JC

El cacheo de páginas (page caching) guarda una copia de las páginas de nuestra página Web para así disminuir el tiempo de carga.

Nota: No confundir los términos página Web (nuestro sitio o aplicación Web, depende del caso) con sus páginas (cada una de las páginas que contiene nuestro sitio).

Es una de las técnicas de optimización Web más usadas. En esta entrada voy a explicar en qué consiste y por qué es tan importante si queremos mejorar el tiempo de carga de nuestra página Web.

Vamos a centrarnos en el lenguaje PHP que es el que usa WordPress y en la optimización de un página Web en WordPress.

El lenguaje PHP

PHP es un lenguaje interpretado.

Eso quiere decir que las intrucciones no se compilan, se ejecutan. Cada vez que en una página aparece instrucciones en código PHP el intérprete las procesa para convertirlas en código que entiende el navegador.

PHP es un lenguaje del lado del servidor.

O lo que es lo mismo: El navegador no entiende PHP, todo se ejecuta en el servidor. Esto puede causar problemas de rendimiento, sobre todo si tenemos nuestra Web alojada en un servidor compartido. Eso as así porque tenemos que esperar a que se procesen las páginas que solicitamos.

Petición de una página al servidor

Para que se entienda todo mejor, vamos a explicar el proceso desde que se pide una página al servidor (introducimos su URL en el navegador) hasta que se obtiene y podemos visualizarla.

Y qué mejor ejemplo que esta misma página; esta entrada de blog.

Una vez que hacemos la petición al servidor para cargar esta página (introduciendo la URL que vemos arriba o pinchando en un enlace que venga hasta aquí), éste la recibe, la estudia, carga los recurso correspondiente (en este caso páginas PHP que muestran una entrada de blog), procesa el recurso, crea la respuesta que va a recibir el navegador y la devuelve.

Vamos a verlo todo por pasos.

Estudio de la petición y carga de los recursos solicitados

Una vez que se recibe la petición hay muchas formas de determinar qué recurso o recursos deben cargarse. No quiero hablar de arquitecturas, ni de modelos MVC, solo voy a centrarme en WordPress.

WordPress se da cuenta de que es una entrada de blog y carga el archivo single.php (hay otros casos donde puede cargar otros archivos, pero no es el caso que nos ocupa).

Procesamiento de los recursos

Aquí es donde el intérprete de PHP viene a nuestro rescate. Tiene que procesar el archivo single.php, que muestro parcialmente a continuación. El resultado final será la página que estás viendo ahora.

<?php get_header(); ?>

<div class="grid-container">
...
<?php while ( have_posts() ) : the_post(); ?>

    <?php get_template_part( 'partials/blog/content', get_post_format() ); ?>

    <?php if ( comments_open() || '0' != get_comments_number() ) comments_template(); ?>
<?php endwhile; // end of the loop. ?>

</div>

<?php get_sidebar(); ?>

</div>
...
<?php get_footer(); ?>

El intérprete solo procesa el código que aparece entre las etiquetas de apertura <?php y de cierre ?>. El resto lo ignora y el servidor lo devuelve tal y como está. En este caso devuelve HTML (entendible por el navegador).

Lo primero que se encuentra es get_header(). Esta función busca el archivo header.php y coloca ahí su contenido. Veamos unas líneas del archivo header.php.

<!DOCTYPE html>
<html <?php language_attributes(); ?>>
<head>
<meta charset="<?php bloginfo( 'charset' ); ?>">
<meta name="viewport" content="width=device-width, initial-scale=1, minimum-scale=1, maximum-scale=1">
 
<?php ut_meta_hook(); //action hook, see inc/ut-theme-hooks.php ?>
 
 ...
 
 <!-- Title -->
 <title><?php wp_title(); ?></title> 
 
 <?php wp_head(); ?>
 
</head>

<body id="ut-sitebody" <?php body_class(); ?> ...

Vemos que en header.php se forma el HTML inicial común para todas las páginas. Las instrucciones PHP devuelven el título de la entrada, los estilos y scripts que hayamos añadido, etc.

Si seguimos procesando single.php, ya una vez procesado header.php, nos encontramos con «el loop». WordPress lo usa para buscar en la base de datos el contenido a mostrar. En este caso muestra el contenido de esta entrada en el formato que se indica.

Luego procesa el archivo sidebar.php (para crear el HTML de la barra lateral). Y por último el archivo footer.php (para crear el pie de página).

En cada archivo hay llamadas a la base de datos, tanto para consultar opciones como para cargar contenido. También puede llamar a funciones para mostrar la fecha en el footer, etc.

Respuesta al navegador

Una vez procesados todos los archivos necesarios para crear la página que hemos solicitado la devuelve al navegador.

Todo este proceso se repite cada vez que pedimos una página al servidor.

Hay que tener en cuenta que el número de operaciones que se ejecutan en el servidor depende de la complejidad de la página. En este caso hemos visto el ejemplo de una página sencilla.

¿Y si tuviéramos en el servidor una copia de la página ya procesada y solo tuviéramos que descargarla? Eso es lo que se pretende con el page caching o cacheo de páginas.

La caché de páginas (page cache)

La caché de páginas contiene una copia de las páginas a las que le hemos aplicado el page caching.

Esa copia puede estar en disco o en memoria. En el primer caso en suele estar en una carpeta dentro de nuestra instalación de WordPress.

Cada vez que pedimos una página que esté dentro de la caché la obtenemos directamente.

El cacheo de páginas y WordPress

Hay muchos plugins que permiten la caché de páginas o page caching, entre ellos destaco:

En el caso de W3 Total Cache nos vamos a las opciones del plugin, habilitamos caché de página (page cache) y elegimos donde queremos que se cree la caché (en caso de duda elegir en disco).

Dentro de las opciones tenemos un apartado Caché de página donde podemos indicar qué páginas queremos cachear, durante cuanto tiempo queremos que se guarde la copia en la caché, etc.

Una vez hemos habilitado el page caching o cacheo de páginas con W3 Total Cache y hayamos elegido disco, podemos ver la caché en el siguiente directorio del servidor dentro de nuestra instalación de WordPress:

/wp-content/cache/

Consideraciones a tener en cuenta

En caso de páginas que se actualicen constantemente hay que estudiar si merece la pena incluirlas en la caché o no.

Por ejemplo, si usamos botones para compartir en redes sociales en páginas cacheadas veremos que el contador no se actualizará hasta que se cree una nueva copia de la página. En este caso se puede poner que se cree una nueva copia de forma rápida. Otro caso donde el page caching puede generar problemas es el de los foros y comunidades.

En general, hay que tener en cuenta que al cargar una página cacheada estamos cargando una versión anterior guardada, por lo que es buena costumbre especificar que se generen nuevas copias cada cierto tiempo.

¡Ojo! Estamos cacheando páginas, ahorrando su procesamiento. Si se cargan estilos anteriores quizás necesitamos generar una nueva copia del caché del navegador (browser cache).

Page caching: Conclusiones finales

Usando un plugin de caché podemos hacer que nuestras páginas se carguen en mucho menos tiempo. He visto casos de páginas donde antes de cachear tardaban entre 5-10 segundos en cargar y tras usar un plugin se cargaron en menos de un segundo.

Puedes usar una herramienta como Pingdom para ver la diferencia entre cachear las páginas o dejar que se procesen en cada petición.

Mi recomendación es cachear todas las páginas siempre que sea posible; sobre todo las principales. Tus visitantes lo agradecerán.

Hay que tener en cuenta también que la mayoría de las páginas no sufren modificaciones. Y si nosotros las modificamos desde el panel de WordPress se crea una copia nueva.

En resumen, el uso de un plugin de caché no debería darte problemas y en general son más las ventajas que los inconvenientes que suponen su uso.