WordPress

Última revisión: 28 de diciembre de 2021

• Configurar WordPress
• WP-Config
  • Conexión a base de datos
  • Contenido
  • Memoria
  • Actualizaciones
  • Rendimiento
  • Lector de feeds
  • Modo Debug
• Crones
  • Deshabilitar el WP-Cron
  • Cron, con WP-CLI
  • Cron, con llamada pública
• Prefetch, preload y preconnect

Configurar WordPress

Cuando instalamos WordPress tenemos una configuración básica pensada para funcionar en cualquier alojamiento web, pero no viene optimizado ni configurado para obtener su máximo rendimiento.

Es por esto que lo primero que deberemos hacer es optimizar la configuración de algunos de sus elementos para mejorar el rendimiento en varios aspectos, y todo pasa por la configuración en el fichero WP-Config.

WP-Config

WordPress dispone de un fichero de configuración llamado wp-config.php que por defecto encontramos en la carpeta raíz de su instalación. Este fichero incluye algunas configuraciones básicas como el usuario y contraseña de la base de datos, el prefijo de las tablas, y las claves de cifrado de las cookies.

Pero este fichero permite mucha más configuración, gran parte de ella que permite la optimización o la no-saturación de algunos elementos como partes de la base de datos o de los tiempos de respuesta del editor.

Si quieres facilitarte el proceso, puedes utilizar el Generador de ficheros WP-Config.

Conexión a base de datos

define( 'DB_NAME', 'your_own_database_name' );
define( 'DB_USER', 'your_own_database_user' );
define( 'DB_PASSWORD', 'your_own_database_password' );
define( 'DB_HOST', 'localhost' );
define( 'DB_CHARSET', 'utf8mb4' );
define( 'DB_COLLATE', 'utf8mb4_general_ci' );

De estas configuraciones, es importante configurar correctamente el DB_CHARSET y el DB_COLLATE. Lo mejor es configurarlos según lo que haya configurado por defecto ya en la propia base de datos, aunque actualmente para WordPress la configuración óptima es la de usar UTF8mb4 y su edición «general».

Con UTF8mb4 podremos almacenar códigos UTF8 de 4 bytes, lo que incluiría, entre otras cosas, que elementos como los emojis o caracteres como cirílico, árabes o kanjis puedan almacenarse de forma nativa en la base de datos.

El DB_COLLATE permite facilitar cómo se van a ordenar los contenidos en un listado. Por ejemplo, si nuestro sitio principal va a estar en español, y queremos que tras la N se ordene la Ñ, podríamos usar un utf8mb4_spanish_ci en vez del utf8mb4_general_ci.

Contenido

define( 'AUTOSAVE_INTERVAL', 30 );
define( 'WP_POST_REVISIONS', 5 );
define( 'MEDIA_TRASH', true );
define( 'EMPTY_TRASH_DAYS', 7 );
define( 'WP_MAIL_INTERVAL', 86400 );

Por defecto WordPress tiene un sistema de autoguardado de los contenidos del editor cada 60 segundos. Podemos gestionar el tiempo si queremos que guarde con más o menos frecuencia con el AUTOSAVE_INTERVAL, por ejemplo cada 30 segundos.

Un elemento importante que deberíamos limitar siempre, es el de las revisiones de un contenido. Cuando creamos, por ejemplo, una entrada, cada vez que le damos a guardar se hace una copia del contenido previo en el que podemos ver los cambios de lo antiguo con lo nuevo. Esto va generando para cada versión una fila más en la base de datos, lo que hace que pueda crecer mucho si editamos mucho los contenidos.

Puede ser interesante que en grandes medios se almacenen muchas copias de un contenido, pero nunca deberían dejarse de forma ilimitada. Para un uso normal, las revisiones de WP_POST_REVISIONS pueden ser 5, 10 o si queremos poner ago muy grande, 100.

Cuando gestionamos los contenidos del Media, y los borramos, por defecto los contenidos se eliminan directamente del disco, no quedan en la papelera como otros elementos. Podemos activar o desactivar la papelera del Media mediante MEDIA_TRASH.

Los contenidos que dejamos en la papelera, por defecto quedan allí durante 30 días. Si no queremos que esos contenidos ocupen mucho espacio en la base de datos, podemos forzar su vaciado a otra cantidad de días, por ejemplo poniendo EMPTY_TRASH_DAYS en 7 días.

Por norma general no mucha gente utiliza el sistema de lectura del correo. Este sistema permite que WordPress acceda a una cuenta de correo y publique los contenidos que encuentra en ese buzón como entradas. Este proceso de lectura se ejecuta cada 5 minutos por defecto, pero si no lo usamos, podemos decirle que solo lo ejecute una vez al día cambiando WP_MAIL_INTERVAL a 86400 segundos.

Memoria

En la sección de optimización de PHP se comenta la posibilidad de limitar los consumos de memoria de PHP por parte de WordPress. Tenemos la posibilidad de limitar el consumo (los picos) tanto en el frontal como en el panel de administración.

El valor para el consumo de memoria del frontal es:

define( 'WP_MEMORY_LIMIT', '128M' );

El valor para el consumo de memoria del panel de administración es:

define( 'WP_MAX_MEMORY_LIMIT', '256M' );

En cualquier caso dependerá mucho de los plugins que utilices, pero si se configura esto desde un principio, y en algún momento, tras la instalación de un plugin, todo va mal, es más probable que sea el plugin el que esté generando alguna situación con el sistema.

Actualizaciones

define( 'AUTOMATIC_UPDATER_DISABLED', false );
define( 'WP_AUTO_UPDATE_CORE', 'minor' );
define( 'CORE_UPGRADE_SKIP_NEW_BUNDLED', true );

Si queremos tener la máxima seguridad y rendimiento de WordPress deberemos mantener al día cada una de las versiones que tengamos. Es por esto que, al menos, deberíamos permitir que WordPress mantenga al día ls versiones menores de la rama en la que estemos. Si por ejemplo tenemos WordPress 5.8.x, que se actualice de forma automática de 5.8.1 a 5.8.2. Estas actualizaciones menores solo corrigen los elementos actuales, por lo que no deben afectar a ningún plugin ni configuración.

Tampoco deberíamos desactivar las actualizaciones y, si queremos mantener limpio de plugins y temas (porque solo tenemos los que necesitamos), podemos deshabilitar la instalación de nuevos contenidos en actualizaciones mayores.

Rendimiento

define( 'WP_CACHE', true );
define( 'WP_CACHE_KEY_SALT', 'bli6w8w9zrqufbfz79:' );
define( 'COMPRESS_CSS', true );
define( 'COMPRESS_SCRIPTS', true );
define( 'ENFORCE_GZIP', true );

WordPress incorpora una serie de sistemas que permiten la optimización de parte del código y de la caché.

Lo primero que debemos hacer es activar la caché interna (WP_CACHE), y configurar un prefijo (WP_CACHE_KEY_SALT) para el almacenamiento de datos. Puede ser cualquiera

Lo siguiente que podemos indicar es si queremos que se ejecute un simple sistema de optimización de ficheros CSS (COMPRESS_CSS) y JavaScript (COMPRESS_SCRIPTS) que por defecto viene desactivado.

Finalmente, el sistema será capaz de generar la respuesta al usuario de los contenidos con compresión gzip (ENFORCE_GZIP) si no estuviera activado en otros niveles (como el servidor web).

Lector de feeds

WordPress incorpora un sistema de lectura de feeds o contenidos externos. Un ejemplo podría ser el listado de próximos eventos que encontramos en el dashboard al entrar al panel de administración. Este sistema usa las bibliotecas MagpieRSS.

define( 'MAGPIE_CACHE_ON', true );
define( 'MAGPIE_CACHE_DIR', 'cache' );
define( 'MAGPIE_CACHE_AGE', 3600 );
define( 'MAGPIE_CACHE_FRESH_ONLY', false );
define( 'MAGPIE_FETCH_TIME_OUT', 5 );
define( 'MAGPIE_USE_GZIP', true );

Podemos configurar que se active la caché y que, por ejemplo, almacene los datos al menos durante 1 hora (3600 segundos).

Modo Debug

WordPress incorpora un sistema de debugging que puede ayudar a encontrar errores cuando un sitio funciona mal, pero que por defecto no deberíamos tener activo.

define( 'WP_DEBUG', false );
if ( WP_DEBUG ) {
  define( 'WP_DEBUG_DISPLAY', false );
  define( 'WP_DEBUG_LOG', false );
}
define( 'SCRIPT_DEBUG', false );
define( 'SAVEQUERIES', false );

Si hemos de activar el sistema de revisión de errores, recuerda que, tras acabar la revisión, se debería desactivar de nuevo.

Crones

Para el buen funcionamiento de WordPress se han de ejecutar una serie de tareas. Estas tareas se ejecutan en segundo plano, por lo que de alguna manera se ha de lanzar un algo que los ejecute. por defecto, cada vez que un usuario visita una página, se lanza el sistema de WP-Cron (wp-cron.php).

Aunque este chequeo consume pocos recursos, si un sitio web tiene mucho tráfico o disponemos de plugins que requieren una ejecución extensa de cálculo, se puede saturar el sistema. De la misma manera, si un sitio tiene poco tráfico, puede que estas tareas no se ejecuten con la frecuencia recomendada.

Para solucionar estos posibles problemas tanto de alto como bajo consumo, lo más recomendado es limitar el uso del cron y lanzarlo de forma controlada y bajo nuestra responsabilidad.

Deshabilitar el WP-Cron

En estos casos, lo mejor es deshabilitar el sistema de crones mediante la configuración del WP-Config.

define( 'DISABLE_WP_CRON', true );
define( 'ALTERNATE_WP_CRON', false );
define( 'WP_CRON_LOCK_TIMEOUT', 60 );

Cron, con WP-CLI

Si tenemos disponible en nuestro servidor WP-CLI, esta es la mejor forma de ejecutar los crones.

En este caso de ejemplo se configura su ejecución cada 5 minutos. A menos que tengas un sitio de alto tráfico o con requerimientos altos (como un comercio electrónico) debería ser suficiente cada 5 minutos, pero se puede reducir la ejecución a cada minuto o aumentar a 10, 15 o 30 minutos, que tampoco sería lo más recomendado.

*/5 * * * * wp cron event run --due-now --path='/webs/usuario/example.com/' >/dev/null 2>&1

Este sistema, además, permite bloquear las llamadas externas al fichero wp-cron.php por lo que, además, aumentaremos la seguridad del sitio.

Cron, con llamada pública

En caso de no disponer de WP-CLI, siempre se puede hacer uso de la llamada directamente de forma pública, aunque es recomendable por seguridad limitar las llamadas a las IP que hagan las peticiones (la propia máquina o el servicio externo que haga las peticiones).

*/5 * * * * wget -q -O - https://example.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1

Además de las llamadas externas, podemos también habilitar un servicio de llamadas externas, sin necesidad de ejecutar las llamadas el propio sitio. En estos casos sí que es muy recomendable limitar las peticiones a la lista de IP que nos de el proveedor.

Prefetch, preload y preconnect

En muchos casos cuando cargamos nuestro sitio web sabemos que vamos a hacer llamadas a elementos externos, a otros hostname, tanto nuestros como de terceros.

Estas llamadas a otros hostname requerirán que se hagan peticiones a las DNS en el momento en el que se encuentre el elemento. Para esto usaremos el sistema de preconnect que básicamente lo que harán es hacer una llamada para pre calcular las DNS antes de que se haga la petición real.

Esta llamada, al hacerse previamente y en paralelo a otros elementos permitirá que se reduzca el tiempo a la hora de cargar el otro elemento.

Cualquier hostname que no sea el propio de dominio debería encontrarse en este sistema de preconnect.

Un ejemplo de llamada podría ser similar a esta:

<link rel="preconnect" href="//example.com/">

Por otro lado, podemos presuponer que cuando un usuario entra en una página que no es la principal del sitio pueda llegar a entrar en ella. O por ejemplo que un artículo que tenemos paginado, tras la página 1 va a cargar la página 2, o que un usuario que está en una tienda acabará llegando al carrito.

Para estos casos podemos plantear cargar en la caché del navegador otra página o contenido para que, en caso de que ello ocurra, lo haga mucho más rápido.

Un ejemplo podría ser similar a este:

<link rel="prefetch" href="/index.html" as="document">

Para acabar, también podemos pre cargar elementos que se van a usar posteriormente en la página. En este caso se puede aplicar con cierta frecuencia a elementos que sabemos que pueden bloquear la carga de la página, como ciertos scripts.

<link rel="preload" href="/critical.js" as="script">

Los valores válidos del parámetro as son:

• audio: <audio>
• document: <iframe> y <frame>
• embed: <embed>
• font: CSS @font-face
• image: <img> y <picture>
• object: <object>
• script: <script>
• style: <link rel=stylesheet> y CSS @import
• track: <track>
• video: <video>
• worker: Workers

Una extensión para WordPress que nos puede ayudar con esta configuración es: