WPO Web Performance Optimization

Revisar +optimizar el código de plugins para WordPress

Post placeholder image

Una de las primeras cosas que aprendemos a hacer al instalar nuestro primer blog es lanzarnos a la búsqueda de plugins con los que añadir funcionalidades o mejorar características propias de WordPress.

Pero ¡¡ojo!! Si no vamos con cuidado ¡podemos convertirnos en los principales culpables de que nuestra página pierda visitas!
El sistema de plugins de WordPress es la característica más importante que ha permitido a este gestor de contenidos llegar a convertirse en la plataforma utilizada por más de 60 millones de blogs.

Tendemos a instalar todo tipo de plugins basándonos solamente en lo que hacen, pero no prestamos atención al cómo lo hacen. Por ello estamos depositando una excesiva confianza en el buen hacer y en la capacidad de optimización del desarrollador del plugin.

Éste es posible que no haya tenido en cuenta blogs con muchas entradas o con un elevado número de visitas, con lo que podemos encontrarnos que un plugin puede funcionar bien en un primer estadio de nuestro blog o con blogs personales con pocas visitas pero, a la que nuestra popularidad aumenta y nuestra página recibe un mayor numero de lecturas, el blog va deteriorándose y reduciendo su velocidad de carga incluso se puede llegar a tener un site caido que no permite nuevas visitas.

Lo anterior podemos verlo como mejor se hace, con un ejemplo.

Un plugin muy interesante, sencillo, pero cumple con su cometido, es KB Linker. En pocas palabras este plugin permite emparejar enlaces (o urls) con palabras o frases. Estas palabras son sustituidas al mostrar el contenido del post.

Por ejemplo, podemos tener una lista de sustituciones como:

SEO->https://seocom.agency/

pruebas de motos->http://www.dailymotos.com/pruebas-de-motos/

Como podemos ver, sin nosotros intervenir se han creado los enlaces. Esto nos proporciona una manera sencilla de cambiar los links sin tocar uno sólo de los posts del blog.

Si en cualquier momento la relacion SEO deja de estar relacionada con https://seocom.agency/ y lo queremos relacionar con https://seocom.agency/es/blog/, solamente debemos modificar la relación y la próxima visualización del post mostrará la nueva dirección.

El problema que presenta este plugin es precisamente esto último que hemos comentado. Cada vez que se muestra el contenido de un post se realiza el proceso de revisar en el texto las palabras sustituibles de la lista. Para ello este plugin se «engancha» al hook «the_content«.

Imaginaos que tenemos un tema que muestra en su homepage, las últimas 15 noticias en la primera parte de la web, luego un bloque de publicidad, seguido de 4 pestañas (Posts de la Categoria 1, Categoria 2…, etc )con 10 titulares y un pequeño extracto. Esto en su parte central, pero también en el lateral añadirmos los últimos posts de una categoria concreta, por ejemplo eventos, que muestran otros 5 posts.

Ya llevamos 60 posts mostrados sólamente en la home.

Imaginad también que no tenemos solamente dos sustituciones en la lista de palabras; tal vez nuestro portal contiene entrádas de carácter técnico y hemos preparado un glosario completo con más de 500 palabras, con su definición y fotografías. Este glosario engrosaria la lista de sustituciones hasta las 500 lineas.

En este punto, sumando las dos condiciones, podemos ver el problema que se nos presenta. Estamos obligando a la máquina a realizar 60 veces un bucle de búsqueda de 500 palabras. Todo ello aderezado con el hecho de que la manera de realizar la búsqueda y sustitución de palabras se consigue utilizando expresiones regulares que son bastante costosas a nivel de ciclos de cpu.

A esto hay que añadirle el propio proceso para cada uno de los posts individuales.

Bien es cierto que utilizando un plugin de cache del estilo de W3 Total Cache conseguiriamos reducir el alto consumo de procesador provocado por el plugin. ¿Pero no sería más óptimo conseguir que el plugin fuera un paso más allá?

La manera en que nosotros hemos resuelto el problema pasa por saber exactamente qué palabras de la lista de parejas están en el contenido de cada post, y una vez conocido ésto, guardarlo junto a los metadatos del post. Con ello podemos acabar reduciendo el bucle de 500 pasadas a unos pocos 5-10 movimientos.

Para ello nuestra modificacion consiste en que antes de cargar la lista de 500 parejas generales, mira en los metadatos del post si hay una sublista. Si la encuentra, la utiliza directamente y finaliza el proceso com siempre.

Si no la encuentra, revisa las 500 palabras y va guardando cada una de las palabras encontradas en un array y al finalizar el proceso realiza un update de los metadatos para este post para tener disponibles estos datos en una próxima visualización del contenido del post.

Pero si guardamos los emparejamientos, ¿que sucede si modificamos, añadimos o eliminamos un emparejamiento?. Es muy sencillo, solamente debemos eliminar los metadatos asociados a los emparejamientos actuales y el sistema automáticamente los volverá a regenerar la próxima vez que se muestren cada unos de los posts de nuestro blog.

En resumen, éste es un breve ejemplo de lo que podemos hacer para coger un buen plugin y convertirlo en un plugin mucho mejor.