Tres trucos para aumentar significativamente el rendimiento de tu WordPress

Como ya sabes a principios de año estrenamos web nueva. Eso significa que me he pasado unos cuantos días en Navidades trabajando como un loco para tenerlo todo disponible.

Por supuesto, como se trataba de un cambio que no iba a poder resolver en unas horitas, creé otra instancia de la página en un subdominio para ir trabajándola, y cuando ya todo estuvo como mínimamente quería que estuviera (el trabajo de diseño y desarrollo en una web es continuo en el tiempo, no termina únicamente cuando sacamos la página), hice el cambio de directorios y listo.

La cuestión, eso sí, es que esto supuso, como era de esperar, un aumento radical del consumo de recursos del servidor. En un servidor que de por sí, para este proyecto, se está quedando justito.

Ergo, una bajada de rendimiento. Lo que complicaba, de hecho, el trabajo más si cabe (algunos cambios no se ejecutaban mostrando una pantalla en blanco, la caché hacía lo que podía…).

En fin, era un problema temporal. Pero es un problema que no es la primera vez que me pasa. Cuando hay picos de tráfico el servidor se resiente. Seguramente el usuario ni se da cuenta (a lo sumo le tardará un pelín más en cargar la página), pero a nivel de administración, si yo estoy haciendo algo, es un completo caos.

Por eso, ya de cambiar el envoltorio, estuve configurando algunos aspectos no tan inmediatos de WordPress para evitar, en la medida de lo posible, sobrecargar un poco más la página.

¿Cómo mejorar radicalmente la carga de nuestro WordPress?

Recalco que los tres truquillos que te comentaré más adelante no van a marcar un antes y un después en la optimización de tu WordPress.

Es más, resulta mucho más productivo realizar algunas de las configuraciones que en su día expliqué, que tienen un impacto muy significativo en la experiencia de usuario, y que te resumo por aquí:

• Que el servidor y la web utilice la última tecnología: Todavía hay muchos hostings que ofrecen versiones por debajo de la 7.0 de PHP o incluso cargan los dominios mediante versiones de HTTP por debajo de la 2. Ya ni hablemos de tener un WordPress no actualizado, o de que este no cargue estrictamente por SSL. En serio, esto reduce mucho la capacidad que tenemos de servir la página en el menor tiempo posible, un factor que ya no solo es crítico para la experiencia de uso sino que también es determinante para el posicionamiento web de nuestro proyecto. De hecho esto es de lo primero que reviso cuando me piden presupuesto para la web de un cliente, y es por tanto lo primero que ofrezco… me hayan contratado para temas de la web, para marketing/publicidad o para reputación. Si las tripas de nuestro proyecto no están bien optimizadas, por mucho que hagamos por encima estaremos en desventaja frente a la competencia.
• Utilizar un sistema de cacheado web potente: Actualmente PabloYglesias utiliza WP-Rocket, que es de pago. Pero estuvimos mucho tiempo utilizando plugins de caché gratuitos que aunque no llegan al nivel de optimización de WP-Rocket, ayudan también.
• Redirigir el tráfico por una CDN: Aunque hubo un tiempo en que por estos lares no teníamos ninguna (limitaciones del servidor y servicios de aquel momento), casi todo el tiempo que lleva PabloYglesias funcionando lo ha hecho mediante la CDN de Cloudflare, que tiene versión gratuita (la que un servidor utiliza). Y no solo consigue hacerle llegar la página más rápida a cada usuario según desde qué país se conecte, sino que además nos bloqueará mucho tráfico de mierda (bots, ataques DDoS sencillitos…) lo que repercute tanto a nivel de optimización de recursos como también a nivel de seguridad, e incluso, si nos ponemos estrictos, de posible censura.
• Cargar las páginas mediante WEBP: Con la llegada de formatos de imagen más óptimos para la web, como es el caso del .webp, se nos abre la veda a arañar otros cuantos recursos en lo que junto a los vídeos y el audio representa el mayor consumo de ancho de banda de una página web, sus imágenes. Ya he explicado cómo lo he hecho yo mediante un plugin freemium, aunque es cierto que WP-Rocket también incluye un sistema semejante.

¿Qué más podemos hacer?

Pero con esto, como decía, no siempre es suficiente. Al menos en mi caso tengo por ahora una limitación de recursos que viene dada por el hosting (a cambio de no tener que admistrarlo, estoy supeditado a las limitaciones de la cuenta y el gasto que hagan los vecinos con los que comparto servidor).

Bajo este prisma, he hecho tres pequeños cambios que han reducido significativamente la carga de recursos periódica. Lo suficiente como para poder afrontar futuras subidas de tráfico y/o trabajo intenso como el que hice estas Navidades con algo más de margen.

A saber:

Limitar o bloquear la carga de Heartbeat en WordPress

WordPress 3.6 introdujo la API Heartbeat, que le permite a tu navegador comunicarse con el servidor cuando inicias sesión en tu panel de administrador de WordPress. Es útil sobre todo para que le muestre a otros autores cuando un post está siendo editado por otro usuario, o que el propio WordPress haga copias de seguridad periódicas de tus posts mientras los escribes, algo que agradecerás sobre todo si de pronto pierdes la conexión (la mayor parte del contenido seguirá estando ahí y no habrás perdido todo el trabajo). Y además es utilizado por algunos plugins (como WooCommerce) para mostrar sus notificaciones en el dashboard.

Sin embargo, sea o no necesario para el uso que le das a tu WordPress, la API de Hearbeat se carga periódicamente según la página donde estés, lo que supone un consumo periódico de recursos. Por defecto:

• En la edición de post, lo hace cada 15 segundos.
• En tu panel de admin, cada minuto.
• …

Cada una de estas llamadas es una carga del archivo wp-admin/admin-ajax.php, que ya de por sí suele ser junto con la home de los archivos más pedidos del servidor. Ergo mayor consumo de recursos para un archivo que realmente no tiene impacto de cara al usuario (no es un post o una página de la web).

Por este motivo podemos o bien limitarlo o directamente bloquearlo.

Si en efecto no necesitamos su funcionalidad (por ejemplo en tu proyecto no tienes colaboradores, por lo que como mucho únicamente estarás tú administrando o editando post), podemos bloquear su carga incluyendo en el archivo functions.php de nuestro child theme o theme la siguiente función:

add_action( 'init', 'stop_heartbeat', 1 );
function stop_heartbeat() {
wp_deregister_script('heartbeat');
}

Si por el contrario, queremos limitarlo, tendremos que hacer uso de algún plugin que nos lo permita. El más conocido y además gratuito es Heartbeat control (ES), de los chicos de WP-Rocket (de hecho en WP-Rocket ya viene por defecto).

Lo instalamos, vamos a Ajustes -> Ajustes de control de Heartbeat y en el menu Heartbeat Behavior elegimos Modificar Heartbeat. Luego seleccionamos todas las Localizaciones y en la barra de Frecuencia elegimos 60 segundos o superior (según queramos).

Este plugin también nos da la opción de desactivarlo por completo.

Limitar el (ab)uso de wp-cron en WordPress

WordPress es un CMS de propósito generalista. Esto quiere decir que tan pronto lo podemos utilizar para crear un blog, como para crear una tienda, una página corporativa, un foro, una red social o lo que se nos ocurra. E incluso dentro de la misma categoría de proyecto podemos tener funcionalidades muy pero que muy diferentes. Funcionalidades, en algunos casos, que necesitan para su operativa que se realicen cada cierto tiempo y/o bajo llamadas expresas del servicio de turno.

Por ello WordPress necesita de una herramienta que gestione las tareas programadas. Prácticamente todos los sistemas operativos y servidores del mercado tienen su propio sistema, llamado habitualmente cronjob.

La cosa es que WP no puede esperar que todos operen de la misma manera, así que para evitar que según dónde tengamos instalado WordPress la herramienta de gestión de tareas programadas funcione de una u otra manera, el propio core del CMS incluye su propio cronjob denominado wp-cron.php, que es un archivo que se ejecuta por defecto CADA VEZ que un usuario entra en la página:

• Si hay tareas pendientes, las ejecuta.
• Si no, pues no hace nada.

Es una buena salida para no depender de un cronjob real, pero tiene sus puntos negativos, ya que como decíamos supone la carga de otro archivo más a priori innecesario para el usuario cada vez que este entra en la página, y abre la veda a que surjan problemas tanto de seguridad (es posible realizar un ataque de denegación de servicio a una página atacando a su wp-cron.php para bloquear el servidor) como de pura funcionalidad (algunos sistemas de cacheado pueden entrar en conflicto con el wp-cron.php, generando mayor tráfico del que era realmente necesario o bloqueando la carga de tareas programadas de antemano).

Para evitar esto, según el hosting que utilicemos es probable que podamos pasar de utilizar el wp-cron.php, cuya variable, como decía, se basa en el tráfico de la web, a un cronjob real basado en el propio reloj del servidor.

En el caso de Siteground, por ejemplo, tienen un tutorial supersencillo de seguir que nos permite habilitar el cronjob del servidor (ES) y dejar por tanto de depender de la carga vía tráfico del wp-cron.

Para ello primero tenemos que desactivarlo en WordPress, incluyendo la siguiente línea en el wp-config.php:

define('DISABLE_WP_CRON', true);

Y activándolo a nivel de CPanel con una línea de código donde le daremos la dirección del wp-cron de nuestro WordPress y el tiempo que queremos que tarde en pasar por él.

Limitar a «los bots malos» el acceso a nuestra web mediante robots.txt

Ya dijimos antes que Cloudflare nos limitaba ya de por sí parte de ese tráfico negativo que podíamos recibir, normalmente automatizado mediante bots.

Ahora bien, si no queremos habilitar un CDN o si queremos acompañarlo de otra herramienta específicamente creada para este menester, deberíamos retocar (o crear si aún no lo teníamos) el archivo robots.txt de nuestro WordPress, que es un archivo de texto que se encuentra en la carpeta raíz de WordPress e informa a los robots de qué tienen permitido hacer y qué no.

De hecho es uno de esos archivos que muchos auditores de seguridad revisan, ya que las malas lenguas dicen que algunos administradores de sitios lo utilizan también con la intención de bloquear el acceso de bots a directorios y páginas de la web que deberían ser privados… y que por tanto pueden ser de interés para alguien que está auditando una página :).

Por aquí te dejo el mío, con etiquetas para explicar para qué sirve cada parte, que es de hecho un popurrí de otros que he visto por la web y de las recomendaciones que hacía Alvaro hace tiempo en su post (ES).

Ten en cuenta que al final hay dos partes que tienes que modificar con las URLs que competen a tu propio dominio:

# Básicamente por aquí permitimos que los bots accedan a los recursos que deberían acceder, y les bloqueamos el acceso a los que no deberían
User-agent: *
Allow: /wp-content/uploads/*
Allow: /wp-content/*.js
Allow: /wp-content/*.css
Allow: /wp-includes/*.js
Allow: /wp-includes/*.css
Disallow: /cgi-bin
Disallow: /wp-content/plugins/ 
Disallow: /wp-content/themes/ 
Disallow: /wp-includes/ 
Disallow: /*/attachment/
Disallow: /tag/*/page/
Disallow: /tag/*/feed/
Disallow: /page/
Disallow: /comments/
Disallow: /xmlrpc.php
Disallow: /?attachment_id*
 
# Bloqueo de las URL dinamicas
Disallow: /*?
 
 
#Bloqueo de búsquedas
User-agent: *
Disallow: /?s= 
Disallow: /search
 
 
# Bloqueo de trackbacks
User-agent: *
Disallow: /trackback
Disallow: /*trackback
Disallow: /*trackback*
Disallow: /*/trackback
 
 
# Bloqueo de feeds para crawlers
User-agent: *
Allow: /feed/$ 
Disallow: /feed/ 
Disallow: /comments/feed/
Disallow: /*/feed/$ 
Disallow: /*/feed/rss/$ 
Disallow: /*/trackback/$ 
Disallow: /*/*/feed/$ 
Disallow: /*/*/feed/rss/$ 
Disallow: /*/*/trackback/$ 
Disallow: /*/*/*/feed/$ 
Disallow: /*/*/*/feed/rss/$ 
Disallow: /*/*/*/trackback/$
 
 
# Ralentizamos algunos bots que se suelen volver locos
User-agent: noxtrumbot
Crawl-delay: 20
User-agent: msnbot
Crawl-delay: 20
User-agent: Slurp
Crawl-delay: 20
 
 
# Bloqueo de bots y crawlers poco utiles
User-agent: MSIECrawler
Disallow: / 
User-agent: WebCopier 
Disallow: / 
User-agent: HTTrack 
Disallow: / 
User-agent: Microsoft.URL.Control 
Disallow: / 
User-agent: libwww 
Disallow: / 
User-agent: Orthogaffe 
Disallow: / 
User-agent: UbiCrawler 
Disallow: / 
User-agent: DOC 
Disallow: / 
User-agent: Zao 
Disallow: / 
User-agent: sitecheck.internetseer.com 
Disallow: / 
User-agent: Zealbot 
Disallow: / 
User-agent: MSIECrawler 
Disallow: / 
User-agent: SiteSnagger 
Disallow: / 
User-agent: WebStripper 
Disallow: / 
User-agent: WebCopier 
Disallow: / 
User-agent: Fetch 
Disallow: / 
User-agent: Offline Explorer 
Disallow: / 
User-agent: Teleport 
Disallow: / 
User-agent: TeleportPro 
Disallow: / 
User-agent: WebZIP 
Disallow: / 
User-agent: linko 
Disallow: / 
User-agent: HTTrack 
Disallow: / 
User-agent: Microsoft.URL.Control 
Disallow: / 
User-agent: Xenu 
Disallow: / 
User-agent: larbin 
Disallow: / 
User-agent: libwww 
Disallow: / 
User-agent: ZyBORG 
Disallow: / 
User-agent: Download Ninja 
Disallow: / 
User-agent: wget 
Disallow: / 
User-agent: grub-client 
Disallow: / 
User-agent: k2spider 
Disallow: / 
User-agent: NPBot 
Disallow: / 
User-agent: WebReaper 
Disallow: /
 
 
# Previene problemas de recursos bloqueados en Google Webmaster Tools, que en principio ya no es necesario, pero por si acaso...
User-Agent: Googlebot
Allow: /*.css$
Allow: /*.js$

# Avisamos de dónde está nuestro sitemap para facilitarle el trabajo de crawling al bot de turno. CAMBIARÁ EN CADA CASO
sitemap: https://www.pabloyglesias.com/sitemap.xml

# Bloqueamos algunas páginas en particular que no tiene sentido que se indexen.CAMBIARÁ EN CADA CASO
User-agent:  *
Disallow: /privacidad/
Disallow: /publicidad-y-patrocinio/
Disallow: /advertising-sponsorship/
Disallow: /aviso-legal/

En fin, que por aquí tienes tres optimizaciones un pelín más avanzadas para minimizar el impacto de ese gasto de recursos no deseado en el servidor.

Algo que a la larga acaba notándose a nivel de web.

Y para cualquier duda o sugerencia, no dudes en contactar conmigo que gustoso te la resolveré.

________

¿Quieres conocer cuáles son mis dispositivos de trabajo y juego preferidos?

Revisa mi setup de trabajo, viaje y juego (ES).

Y si el contenido que realizo te sirve para estar actualizado en tu día a día, piensa si te merece la pena entrar en el Club Negocios Seguros y aprovecharte de todo el contenido exclusivo que publico para los miembros.