WPO WordPress: Mejora la velocidad de carga de 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:
- Reducir el número de peticiones HTTP: para ello, debemos minificar y reducir ficheros javascript, CSS y, siempre que nos sea posible, usar Sprites CSS.
- Paralelizar peticiones HTTP: Aunque pudiera parecer que está relacionado con el punto anterior, no es así directamente. Los navegadores descargan contenidos simultáneamente, podemos aprovecharnos de esto utilizando un CDN o un sistema de Domain Sharding.
- Cuidar el tamaño y orden de los componentes: El tamaño sí importa; a veces es mejor uno grande que muchos pequeños y otras es mejor muchos medianos que uno grande. Además, también influye el orden en que llamamos a estos componentes; mejor CSS en la cabecera y javascript en el pié de página.
- Evitar 404: Si un fichero (imagen, CSS o JS) dejan de existir, el navegador puede quedarse atascado buscándolo. Intenta evitarlo comprobando que todos los ficheros están donde deben. Si no es así elimina su llamada.
- Sobre CSS y JS: Aunque ya he comentado varias cosas a tener en cuenta sobre estos ficheros, me reafirmo en algunas: Intenta externalizar algunos de ellos (para paralelizar peticiones), haz que sean cacheables y minifícalos (haz que sólo sean un fichero).
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:
- Cacheo de las páginas.
- Cacheo de la base de datos.
- Cacheo de objetos (Object Caching).
- Opcode Caching.
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:
- Elimina las revisiones de entradas.
- Elimina los comentarios no aprobados o spam.
- Elimina los comentarios de la papelera.
- Elimina los metadatos de Akismet para comentarios (son muchos, creeme).
- Elimina otros metadatos de los comentarios que son prescindibles.
- Limpia los autoguardados en borradores.
- Limpia la papelera de entradas.
- Aplica acciones predeterminadas de WordPress para optimizar las tablas de la base de datos.
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.
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
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.
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
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.