WPO WordPress: Mejora la velocidad de carga de WordPress

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

¡MANTENME INFORMADO!

¡Gracias por tu interés en estar informado del próximo lanzamiento de mis cursos! 😎

¡No hago spam! Lee la política de privacidad para tener más información.

4 comentarios en “WPO WordPress: Mejora la velocidad de carga de WordPress

  1. Hola Darío, muchas gracias por la entrada, llegué desde un artículo sobre nichos en vivir al máximo que te enlazaba.

    Acabo de realizar pruebas añadiendo lo que tienes en tu htaccess y midiendo con gtmetrix y los valores que me dan son algo peores que sin ellos, aunque si de esa manera se descargan menos archivos (por lo que se ve he casi llegado al tope de bandwith en alguna ocasión) pues merece la pena dejarlo puesto aunque tarde unos milisegundos más.

    No sé si te importa que te comente lo que me ocurre, la cosa es que en mi htaccess yo ya tengo esto:

    # BEGIN WPSuperCache
    # END WPSuperCache

    # BEGIN WordPress

    RewriteEngine On
    RewriteBase /
    RewriteRule ^index\.php$ – [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]

    # END WordPress

    No sé si eso influye con el código que tú tienes puesto, que lo único que hice fue copiarlo y ponerlo justo encima de éste que te he escrito.

    Aparte más abajo hay algo más de código distinto para negar IPs y demás, que desde ukrania me tienen la cabeza loca con tantos intentos de acceso (a ver si doy con un rango de todo el país para caparlo y así no tener que pagar la suscripción de wordfence para quitar el acceso del país, que no es barata).

    Por cierto, en otro artículo tienes explicado a qué robots dar acceso? Googlebot y googlebot image me están consumiendo mucho ancho de banda, pero lógicamente a ellos no puedo caparles, sin embargo el resto que no sea imprescindible, quitando yahoo o bing, que quizá traiga alguna visita, estoy por quitarlo para consumir menos bandwith.

    Muchas gracias y perdona tantas preguntas.

    Un saludo

    1. Hola Jorge, perdona por tardar en responder, un mes de locos.

      Lo que comentas del htacces, cada servidor es un mundo; puedes conseguir que cargue más rápido o el efecto contrario. Pero ten en cuenta que las herramientas, herramientas son. Con esto quiero decir que GTMetrix (o la herramienta de análisis que sea) no tiene la última palabra, sólo sirve de guía. En mi experiencia, todo lo que sea «aligerar» las consultas es bien.

      Sobre bloquear robots, no tengo nada; pero tendrás que ver cuáles te visitan y cuáles te interesa respetar/bloquear.

      Un saludo.

  2. Hola Darío

    Me gustaría optimizar la precarga de las fonts como lo haces tú, pero al usar rel=»preload» y rel=»stylesheet» solo me carga la primera etiqueta que ponga y si es preload no me carga los estilos css.

    Estoy usando Oxygen y encontré un código para la carga incluyendo la etiqueta onload.

    Pero al incluir onload=»this.rel = ‘stylesheet'» no me lo permite el fichero de .php y no se como incluirlo.

    Yo deseo incluirlo en el siguiente código:

    if ( $family ) {
    echo »;
    }

    Sabes cómo puedo hacerlo?

    Gracias Darío

    1. Pues el preload, aparte de tener un bug en Firefox que lo hace no funcionar, es algo confuso de usar… Yo estoy haciendo diferentes pruebas a ver dónde «llora» menos la herramienta de análisis. He probado con un CSS con los font-faces aparte, haciendo el preload de los ficheros de las fuentes directamente, etc.

      Esta última creo que es la correcta, aunque tampoco lo tengo del todo claro.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*

*

DARÍO BALBONTÍN FERNÁNDEZ es el Responsable del tratamiento de los datos personales del usuario y le informa que estos datos serán tratados de conformidad con lo dispuesto en el Reglamento (UE) 2016/679 de 27 de abril (GDPR) y la Ley Orgánica 3/2018 de 5 de diciembre (LOPDGDD), por lo que se le facilita la siguiente información del tratamiento: Fin del tratamiento: mantener una relación comercial y el envío de comunicaciones sobre nuestros productos y servicios. Criterios de conservación de los datos: se conservarán mientras exista un interés mutuo para mantener el fin del tratamiento y cuando ya no sea necesario para tal fin, se suprimirán con medidas de seguridad adecuadas para garantizar la seudonimización de los datos o la destrucción total de los mismos.Comunicación de los datos: No se comunicarán los datos a terceros, salvo obligación legal. Derechos que asisten al usuario: Derecho a retirar el consentimiento en cualquier momento. Derecho de acceso, rectificación, portabilidad y supresión de sus datos y a la limitación u oposición al su tratamiento. Derecho a presentar una reclamación ante la Autoridad de control (agpd.es) si considera que el tratamiento no se ajusta a la normativa vigente. Datos de contacto para ejercer sus derechos: contacto@dariobf.com.