wpo-wordpress

A raíz de mi tutorial de WPO para front-end sois muchos los que me preguntáis si tendrá más partes o si haré uno para WordPress.

En realidad, poco después de terminar esa serie de tutoriales (son 4) de optimización WPO en el front end, redacté uno sobre WordPress.

El caso es que, como no me gusta abusar de los plugins, no había lanzado este artículo por recomendar demasiados.

¿Qué me ha hecho cambiar de opinión? Pues la utilidad de esta entrada. Aunque recomiende plugins en vez de códigos, creo que es un buen artículo para mejorar la velocidad de carga de WordPress.

Dividiré este mini-tutorial en varias partes, donde explicaré cómo optimizar WordPress tanto a nivel de cliente como de servidor. Veremos cómo mejorar la plantilla, hablaremos sobre plugins y un poco sobre servidor.

Mejorar la plantilla o theme de WordPress

Una plantilla de WordPress, salvo las consultas que realizan las funciones del mismo a la base de datos, no deja de ser front-end; y como tal, te recomiendo que veas mi guía de wpo para front-end (son 3 partes).

A modo de resument (insisto, lee esa guía, está todo mucho mejor explicado), tendremos que cuidar los siguientes factores:

En resumidas cuentas, estos son los factores que pueden afectar al front-end (hay más), pero los que más pueden entorpecer la carga son estos.

Cachea en WordPress

Aunque WordPress gestiona su propia caché, que se puede activar desde WP-config.php con una línea, mi recomendación en esta ocasión es utilizar un plugin para gestionarla de manera más óptima. ¿Cuál? Con el que te sientas más cómodo. Como sé que me vas a pedir que "me moje", yo siempre recomiendo WP Super Cache, fácil de configurar y muy bueno en sus labores.

Cacheando a nivel cliente
No obstante, algunos analizadores WPO nos pueden decir que debemos incrementar las cabeceras de cacheado de lado cliente (algo como browser caching).

Tranquilo, te explico este concepto de forma rápida: El Browser caching es un parámetro que se especifica en las cabeceras de los ficheros como tal (cualquier imagen, fichero CSS, JS y demás). ¿Podemos modificar estas cabeceras? Poder... se puede, pero no es recomendable. Lo suyo es, a nivel servidor, decirle al cliente (el navegador web en cuestión) el tiempo de caducidad que va a tener ese tipo de fichero.

Por ejemplo, la imagen de un artículo en WordPress no es habitual que cambie, por lo que podemos decirle al navegador que en vez de 2 días de cacheo, le dedique 1 mes. De esta manera, si un usuario visita nuestro sitio web de forma recurrente, las imágenes no las descargará por un mes.

A continuación, os dejo el fichero .htaccess que utilizo yo, donde especifico por tipo de fichero la caducidad:

# ------------------------------------------------------------------------------
# | Expires headers                                                            |
# ------------------------------------------------------------------------------
 
# Serve resources with far-future expires headers.
 
# IMPORTANT: If you don't control versioning with filename-based cache
# busting, consider lowering the cache times to something like one week.
 
<ifmodule mod_expires.c>
 
    ExpiresActive on
    ExpiresDefault                                      "access plus 1 month"
 
  # CSS
    ExpiresByType text/css                              "access plus 1 year"
 
  # Data interchange
    ExpiresByType application/json                      "access plus 0 seconds"
    ExpiresByType application/ld+json                   "access plus 0 seconds"
    ExpiresByType application/vnd.geo+json              "access plus 0 seconds"
    ExpiresByType application/xml                       "access plus 0 seconds"
    ExpiresByType text/xml                              "access plus 0 seconds"
 
  # Favicon (cannot be renamed!) and cursor images
    ExpiresByType image/x-icon                          "access plus 1 week"
 
  # HTML components (HTCs)
    ExpiresByType text/x-component                      "access plus 1 month"
 
  # HTML
    ExpiresByType text/html                             "access plus 0 seconds"
 
  # JavaScript
    ExpiresByType application/javascript                "access plus 1 year"
 
  # Manifest files
    ExpiresByType application/manifest+json             "access plus 1 year"
    ExpiresByType application/x-web-app-manifest+json   "access plus 0 seconds"
    ExpiresByType text/cache-manifest                   "access plus 0 seconds"
 
  # Media
    ExpiresByType audio/ogg                             "access plus 1 month"
    ExpiresByType image/gif                             "access plus 1 month"
    ExpiresByType image/jpeg                            "access plus 1 month"
    ExpiresByType image/png                             "access plus 1 month"
    ExpiresByType video/mp4                             "access plus 1 month"
    ExpiresByType video/ogg                             "access plus 1 month"
    ExpiresByType video/webm                            "access plus 1 month"
 
  # Web feeds
    ExpiresByType application/atom+xml                  "access plus 1 hour"
    ExpiresByType application/rss+xml                   "access plus 1 hour"
 
  # Web fonts
    ExpiresByType application/font-woff                 "access plus 1 month"
    ExpiresByType application/font-woff2                "access plus 1 month"
    ExpiresByType application/vnd.ms-fontobject         "access plus 1 month"
    ExpiresByType application/x-font-ttf                "access plus 1 month"
    ExpiresByType font/opentype                         "access plus 1 month"
    ExpiresByType image/svg+xml                         "access plus 1 month"
 
</ifmodule>

Cacheando a nivel servidor
Para cachear a nivel servidor, mi recomendación es utilizar Varnish o algún servicio similar. No obstante, plugins como W3 Total Cache gestionan este tipo de cosas. Aquí poco os puedo recomendar:

Como digo, en este ámbito no soy un gran conocedor, mejor que busques información sobre este tema por otro lado.

Algunas recomendaciones extras que ayudarán en WordPress

Como no todo es cachear o pulir ficheros, a continuación os enumero algunos de los aspectos que repercuten directamente en la carga de WordPress.

Base de datos
Es casi el pilar más importante de WordPress; cualquier consulta (artículo, página, adjuntos, menús...) va asociada a una consulta a la base de datos. Si no cuidamos la misma, estamos entorpeciendo (considerablemente) la carga de nuestra instalación.

Puedes utilizar WP-Optimize para mejorar la respuesta y optimización de la base de datos de WordPress; este plugin realiza las siguientes acciones:

Además, este plugin me parece maravilloso porque sólo lo pueden utilizar administradores, automatiza la optimización (yo lo tengo activado una vez por semana), no utiliza códigos extraños (las acciones que utiliza para optimizar son las propias de WordPress) y, lo más importante, permite seleccionar el número de semanas a guardar cuando hacemos limpieza (para no borrar contenidos no deseados).

Uso de imágenes
Como comprenderás, un blog tiene muchas imágenes, aunque en mi caso no sea así por la gran cantidad de artículos técnicos que tengo.

Vamos, que las imágenes son una parte importante a la hora de manejar una instalación de WordPress.

Mi recomendación es optimizarlas con herramientas como Photoshop a la hora de guardar e ImageOptim (para Mac) después de guardarla.

No obstante, entiendo que no siempre utilizamos imágenes creadas con photoshop sin que muchas salen directamente de la cámara. Para estos casos recomiendo (muy mucho) WP Smush.it, que se encargará de optimizar tus imágenes "al vuelo", según las subas a tu WordPress.

Además, siempre recomiendo JetPack, pero no en su totalidad, más bien por un módulo llamado Photon, que hace las veces de CDN, utilizando los servidores de WordPress.com.

Minificación de ficheros HTML, CSS y Javascript
Como os comentaba en el primer punto, es importante hacer una optimización del front-end. En WordPress es complicado, ya que cada plugin (si lo necesita) inyecta su propio fichero CSS, javascript o lo que fuera.

Para estos casos, recomiendo WP Minify Fix, un plugin que minificará el HTML, CSS y JS; y lo hará bastante bien.

¿Hasta qué punto optimizar?

Esta es una cuestión que deberíamos hacernos todos. Es muy desafiante utilizar un analizador tipo GTMetrix y querer ser el mejor de la clase, pero... ¿Es lo mejor para la página?

La respuesta es que no siempre. No siempre es mejor comprimir todos los ficheros CSS en uno, no siempre es importante tener una puntuación alta en estos analizadores, no siempre es mejor cachear a todos los niveles (tampoco siempre es posible, depende de nuestro servidor) y no siempre menos peticiones HTTP implican un sitio web más rápido.

Sobre este punto, te recomiendo leer el artículo que han publicado en WP Rocket, sobre 5 mitos de la optimización de carga (En inglés)..

Mi consejo es que no os volváis locos, optimizar está bien, pero como en todo... los excesos no son buenos.

Si te ha resultado útil este artículo, no dudes en compartirla (utiliza los botones de debajo) y sígueme en Twitter para conocer más aspectos de WPO.

Más información sobre cache y optimización de Base de Datos.

Derechos de imagen