Desastres varios con WordPress

Creo que en las últimas semanas no me había encontrado con tan elevada cantidad de WordPress tan mal configurados. Y es que aunque WordPress es un gran sistema de gestión de contenidos (principalmente para blogs) en cuanto montas algo con cara y ojos y tienes más de 1.000 visitas al día el rendimiento del gestor de contenidos que viene por defecto (y con la configuración por defecto) es una castaña.

Estos últimos 3 meses me ha tocado documentar una base de infraestructura ideal para montar el software y, poco a poco, ir mejorándolo hasta llegar a lo que pensamos que puede ser una estructura ideal. No es fácil, ya lo digo, pero sin duda permite una escalabilidad que no habíamos podido tener.

Lo bueno de WordPress es que permite crecer de muchas maneras, y lleva elementos de serie (aunque no activados) que mejoran mucho la plataforma. Por ejemplo, la caché que lleva internamente es muy decente. Quizá la situación se complica cuando empezamos a meter plugins y otros elementos que lo complican en exceso.

Para empezar, algo tan básico como el fichero de configuración. No es suficiente con configurar la base de datos, sino que ejecutar la URL que te da las “claves aleatorias” para las cookies ya aumenta la seguridad muchísimo, porque, en caso de creer que te has dejado el ordenador con tu sesión abierta en cualquier lugar y correr peligro, tan sólo hay que regenerar estas claves para que se desloguee cualquier usuario y tenga que acceder y validar la clave si no la ha puesto. Otras cosas como cambiar el nombre del prefijo de la tabla por defecto (de wp_ a loquesea_) permitirá que ataques de inyección de SQL puedan quedar inútiles.

Aparte de cambiar el idioma define('WPLANG', 'es_ES'); también debemos activar la caché define('WP_CACHE', true); (que activará la caché interna del propio WordPress, sin necesidad de ningún plugin… aunque no es la mejor configuración, algo ayuda. Otras formas de evitar problemas es reducir las entradas históricas hasta eliminarlas define('WP_POST_REVISIONS', false); y activar un sistema que tenga autoguardado para que, mientras escribes tus entradas, se vaya guardando cada, por ejemplo, 120 segundos define('AUTOSAVE_INTERVAL',120);. Si tenéis un blog ya funcionando, podéis instalar, ejecutar, y desinstalar el plugin Better Delete Revision que os ayudará con la limpieza de basura antigua.

Ahora que ya tenemos la configuración base tocaría montar todo el sistema de estáticos para WordPress. Con esto te aseguras la velocidad de carga sin medida de las imágenes y otros elementos.

Y para acabar viene la reconfiguración de la caché. Personalmente utilizo y seguiré utilizando el wp-caché de Ricardo porque no es un plugin de caché, sino que reconfigura la caché interna del propio WordPress. En mi caso lo configuro para que cachee elementos al menos 24 horas. Una vez tenemos esto, ya lo últimos es meter una capa de Varnish por encima, con una configuración específica que nos hemos ido creando para este CMS (y que hace que, por ejemplo las cosas del panel de Administración no se cacheen, o que los comentarios no den errores…).

Para acabar, los plugins… la gente suele instalar “cualquier plugin” porque cree que está bien o hace lo que quiere, pero no todos los plugins están bien programados, y cosas que se pueden programar fácilmente (por ejemplo con códigos óptimos que hay por la red) se complican con plugins que hacen peticiones interminables a la base de datos y aumentan el tiempo de carga hasta los 2 segundos cuando deberían quedarse en menos de 1 segundo. Sin duda, cuando alguien me pide los plugins que uso o la posibilidad de añadir uno o cambiar por otro es una tarea bastante elevada que no es fácil de realizar.

Ahora, mi siguiente paso, es el de intentar eliminar las funciones deprecated y así reducir finalmente el consumo de memoria con elementos antiguos que no deberían usarse ya que existen funciones nuevas que las sustituyen…

Como decía, en estas últimas semanas me ha tocado optimizar cerca de 10 blogs (algunos de 100 visitas/día, otros de 15.000 visitas/día) con parte de estas herramientas… la velocidad de carga ha aumentado de forma exagerada y sin duda es un placer navegar por los sitios, cuando antes era algo insoportable.

8 comentarios en “Desastres varios con WordPress”

  1. Muy interesante. Es lo que siempre me ha dado un poco de respeto de los editores de contenidos, como WordPress y Joomla: que cuando el sistema crece, todo se puede complicar.

    Pero viendo tus consejos, me quedo un poco más tranquilo :-).

    Gracias por el artículo, muy interesante y de gran ayuda.

    Un saludo.

    Andres.

  2. me parece muy interesante esto que mencionas. Yo soy fanático del wp y me gustaría saber más de esto. ¿Recomiendas algún sitio o texto en dónde pueda profundizar sobre esto que escribes?
    saludos.

  3. Todo esto han sido unas cuantas semanas experimentando… la verdad es que no sé si hay mucha documentación sobre esto, ya que son cosas que hemos vivido el equipo que estamos trabajando en ello… y por eso hice estos apuntes.

  4. Has probado W3 Total Cache? A mi me funciona de maravilla y soluciona prácticamente todos los problemas en la velocidad de carga de WordPress.

  5. Sí, he probado varios, pero como decía, lo importante es tener activada la propia caché del WordPress y luego tener una capa por encima de un sistema de web-caché. En este caso la calidad del sistema de caché ya no es tan detallista, ya que el wp-caché aumenta el rendimiento un 500%.

  6. Hola,

    2 puntos:

    1- comentas: “cambiar el nombre del prefijo de la tabla por defecto (de wp_ a loquesea_) permitirá que ataques de inyección de SQL puedan quedar inútiles.” Sabes lo que es un SQL injection? así previenes el SQL injection en tus aplicaciones? :S
    2- Como sabes que wp-cache aumenta un rendimiento el 500%, como lo has medido? enseñanos esos datos por favor

    w3total cache hace bastantes mas cosas. Me parece más completo y actualizado.

    saludos

    pd: tu que eres un SEO? es la primera vez que entro, pero luego he visto una entrada que pone el SEO ha muerto, entonces, a que te dedicas? está claro que no a la prevención de ataques SQL ;) bueno encantado igualmente

Deja un comentario