El rendimiento de WordPress es una parte crítica de la gestión de un sitio web. Debes monitorearlo para conocer la cantidad de visitantes simultáneos, la velocidad de carga y su disponibilidad constante en línea. Esto es especialmente importante porque los datos sobre estas áreas te ayudarán a tomar decisiones cruciales.
Si eres un socio de anuncios de Grumft, bienvenido a nuestro blog. Si aún no lo eres, esperamos que este contenido te motive a conocer nuestras soluciones exclusivas de programación para editores, desarrolladores de aplicaciones y anunciantes. En este artículo, comprenderás los cuellos de botella más comunes que hacen que WordPress sea más lento y aprenderás cómo corregirlos.
Index
¿Por qué preocuparse por el rendimiento de WordPress?
Antes que nada, debes tener en cuenta que un sitio web rápido puede aumentar los ingresos por anuncios y la retención de usuarios. Sin embargo, identificar los cuellos de botella es solo el primer paso. A continuación, deberás corregirlos.
Estructura de datos y algoritmos
En un entorno normal, PHP proporciona la funcionalidad mientras que MySQL almacena la mayoría de los datos en WordPress. Pero existen variantes, como entornos de alojamiento como Linux o Windows y servidores web proporcionados por Apache, NGINX o IIS. A menudo, sufren de las mismas trampas y restricciones generales.
PHP y MySQL
Normalmente, saber que PHP y MySQL son los componentes principales y las áreas donde suelen ocurrir problemas es suficiente. Una nueva página, elementos de menú y tipos de publicaciones personalizadas se representan como una línea en la base de datos. Sin embargo, los datos no contenidos en esta única línea también se dispersan en otros registros. Esto incluye campos personalizados, taxonomías (etiquetas, categorías, etc.), información de usuario, entre otros componentes no enumerados de otra manera.
El sistema de archivos almacena el código PHP o las imágenes, entre otros recursos. En la mayoría de las solicitudes realizadas a tu sitio web (incluidas las llamadas AJAX), la mayor parte de tu base de código PHP de WordPress, así como cualquier complemento activo y funciones de temas, representan la mayor parte de la carga de la CPU en un entorno de alojamiento.
Excepción
Un sitio en caché, donde el trabajo se realiza solo periódicamente y la respuesta resultante se guarda para visitas repetidas (a expensas de la memoria y/o el almacenamiento, junto con la sobrecarga de generar esta copia en caché).
Consideraciones básicas de rendimiento de WordPress
La optimización del rendimiento web no está disponible como una característica lista para usar. Por lo tanto, debes estar atento y seleccionar cuidadosamente las herramientas y técnicas para mejorar el rendimiento de tu sitio web de WordPress.
Carga perezosa y solicitudes asincrónicas («AJAX»)
La mayor preocupación en los sitios web monetizados con anuncios es, sin duda, la capacidad de respuesta percibida. Si una sola solicitud consume muchos recursos o tiene un rendimiento insatisfactorio, debes dividirla en varias tareas más pequeñas que ocurran al mismo tiempo.
Por ejemplo
Supongamos que una página web tarda tres segundos (3000 ms) en responder de la siguiente manera:
- 150 ms: genera un encabezado de página con menús personalizados e información dinámica generada en tiempo de ejecución;
- 700 ms: recupera los campos de publicaciones y personalizados de la base de datos y los utiliza para generar la estructura de la página;
- 1800 ms: busca en la base de datos todos los eventos (tipo de publicación ficticia que representa un evento de calendario) que ocurren después de hoy, los clasifica y genera un widget de calendario que los lista;
- 350 ms: genera las barras laterales y los pies de página, incluidos otros widgets variados y elementos de navegación. Cómo resolverlo
Como puedes ver, el sitio tarda 1800 milisegundos en producir el widget de calendario. Si no es posible reducir el tiempo necesario para generar este widget, tal vez tenga más sentido omitir este elemento en el primer paso y usar la carga perezosa después de que se complete la renderización de la página.
Podría quedar así:
- 150 ms: genera un encabezado de página con menús personalizados e información dinámica generada en tiempo de ejecución;
- 700 ms: recupera los campos de publicaciones y personalizados de la base de datos y los utiliza para generar la estructura de la página;
- 350 ms: genera barras laterales y pies de página, incluidos otros widgets variados y elementos de navegación (la página se ha cargado en este punto [1250 ms] y el usuario puede ver su contenido sin el widget de calendario);
- 2000 ms: solicitud AJAX para buscar en la base de datos todos los eventos (tipo de publicación ficticia que representa un evento de calendario) que ocurren después de hoy, los clasifica y genera un widget de calendario que los lista.
Como puedes notar, el tiempo total aumentó en un total ficticio de 200 ms. En parte, esto se debe a que la solicitud AJAX separada requiere que el servidor cargue todo el código base de PHP nuevamente.
Sin embargo, a pesar del tiempo adicional, es probable que el usuario perciba que el sitio se carga más rápido. En la experiencia del usuario, el sitio responderá después de 1250 ms y luego aparecerá el calendario. El usuario apenas notará el calendario durante este período, lo que mejorará su experiencia general en el sitio.
«Ida y vuelta»
«Ida y vuelta» describe el proceso de comenzar desde un recurso, consultar otro y devolver los resultados al primero. Los escenarios incluyen consultas de bases de datos de PHP (una línea de código ejecuta una consulta SQL y recupera los resultados) o un navegador solicitando una página web (una llamada AJAX o la obtención de una imagen u otro recurso).
Debido a la sobrecarga necesaria para realizar el proceso «ida y vuelta» de un recurso a otro, estos deben tratarse con cuidado y realizarse solo cuando sea absolutamente necesario. Es importante que realices el menor número posible de estos procesos para un rendimiento óptimo.
Algunas de estas situaciones pueden evitarse ajustando cuidadosamente.
Por ejemplo
Considera una página de archivo con las 5 publicaciones más recientes (un escenario común en WordPress). Un enfoque para esto podría ser identificar primero las publicaciones más recientes y luego, para cada una, volver a la base de datos y solicitar los detalles de cada publicación (6 viajes de ida y vuelta a la base de datos). Un enfoque más limpio sería una sola consulta SQL que enumere las 5 publicaciones más recientes y devuelva toda la información sobre ellas en su respuesta (realizando un solo viaje de ida y vuelta). Esta respuesta será más grande en tamaño que las solicitudes individuales por separado, pero debería ser considerablemente más rápida a largo plazo.
Ajax
Considera lo mismo al hacer que una página sea pesada en AJAX. Cada solicitud (también considerada un «hilo» en este contexto) puede ejecutarse simultáneamente, o el servidor puede ver el orden en que se solicitaron y ponerlas en una cola. El rendimiento del servidor en estas condiciones depende en gran medida de su configuración (un núcleo de CPU o muchos, el modelo de enhebrado del servidor web, etc.).
Esto se agrava por la cantidad de sobrecarga de datos (encabezados HTML, tramas Ethernet) generados por cada solicitud que debe tratarse, así como por la sobrecarga de procesamiento en el servidor para cada una de estas solicitudes. Al igual que en la consulta a la base de datos, a menudo hay oportunidades para agrupar cosas para aumentar la eficiencia, pero esto debe equilibrarse en relación con el tiempo de ejecución percibido. En otras palabras, estamos viendo el otro lado de la moneda del cargador lento.
No hay una verdad absoluta, ya que cada situación debe evaluarse individualmente. Sin embargo, un programador menos experimentado puede no identificar esto como un área de preocupación y, por lo tanto, ignorarla al ajustar el rendimiento.
Caché
Como dijimos antes, PHP es un lenguaje interpretado y el código se evalúa en tiempo de ejecución. Esto puede verse afectado por «inclusiones» dentro del código.
Por ejemplo
WordPress puede usar condicionalmente un archivo PHP en una situación, pero no en otra, por lo que el tamaño de tu código puede variar según la naturaleza de la solicitud.
Esto es aún más evidente en los complementos de WordPress, que son bases de código PHP que se cargan dinámicamente cuando están presentes y activos. Debido a esto, activar un complemento con un código deficiente puede tener un efecto devastador en el rendimiento.
Además, si el contenido del sitio no cambia con frecuencia y es consistente durante largos períodos de tiempo, cada consulta en la base de datos continuará devolviendo los mismos datos que en ocasiones anteriores.
Aunque un sofisticado sistema de administración de bases de datos relacionales (RDBMS) podría darse cuenta de que los datos no han cambiado desde la última solicitud y podría devolver una copia en caché, es más seguro suponer que debe realizar el mismo trabajo cada vez que lo hizo por primera vez.
Cuándo usar caché
En tales situaciones, puede ser ideal implementar una o más capas de caché. Pueden implementarse de varias formas y, aunque no es posible considerar todas las situaciones.
Datos de terceros
Una situación que se encuentra con frecuencia es el uso de una API o fuente de datos de terceros. Esto ocurre de diversas formas, como fuentes de eventos iCal, feeds RSS, integración con Facebook o Twitter, CRM de terceros, etc. El flujo de trabajo para esta integración puede ser similar a:
Solicitudes de usuarios en tu sitio web Tu sitio web recibe la solicitud Tu sitio web hace una solicitud a la API de terceros La API de terceros responde Tu sitio web procesa la respuesta Tu sitio web responde al usuario
En el escenario anterior, la mitad de los pasos (del 3 al 5) representan el trabajo necesario para manejar la integración de terceros. Considera el asunto desde el punto de vista geográfico o logístico; el usuario puede estar en Buenos Aires, Argentina, pero tu sitio web puede estar alojado en Ciudad de México, México, y la aplicación de terceros puede estar alojada en Madrid, España.
Por ejemplo
Suponiendo un salto teórico de 60 ms entre cada uno de estos puntos y una sola solicitud/respuesta necesaria para realizar cualquier comunicación entre dos puntos, un «ida y vuelta» se mapearía a:
Buenos Aires a Ciudad de México (pasos 1 y 2): 60 ms Ciudad de México a Madrid (paso 3): 50 ms Madrid a Ciudad de México (paso 4): 50 ms Ciudad de México a Buenos Aires (paso 6): 60 ms
El ejemplo anterior suma un total de 220 ms. Si la aplicación de terceros se elimina del proceso, el número se reduce a 120 ms (casi la mitad del tiempo). En realidad, cualquiera de estos tres saltos puede variar desde 15 ms hasta 150 ms (o más) según las condiciones.
Consideraciones de rendimiento del lado del cliente
Los ejemplos anteriores se centran principalmente en las consideraciones de rendimiento en el lado del servidor. Sin embargo, la aplicación de la lógica de rendimiento en el lado del cliente es igualmente crítica.
JavaScript
La optimización y la selección de bibliotecas JavaScript son vitales para un rendimiento sólido. A menudo, se utilizan bibliotecas como jQuery para simplificar el trabajo, pero estas bibliotecas son abstracciones y, a veces, generan sobrecarga.
Por ejemplo
Digamos que necesitas recorrer una lista de 10 elementos de lista (un escenario bastante común en la mayoría de los sitios web) para verificar cuáles tienen una clase de «artículo reciente» y cuáles no. Esto puede hacerse con solo unas pocas líneas de código en JavaScript (sin bibliotecas) y en realidad tomaría menos tiempo que cargar la biblioteca jQuery desde un servidor.
Un desarrollador menos experimentado podría inclinarse a utilizar jQuery (o cualquier biblioteca) porque «es más fácil» o porque no entiende completamente cómo usar JavaScript básico en esta situación. Sin embargo, las sobrecargas asociadas con el uso de estas bibliotecas superan con creces la ganancia en comodidad.
Recursos web
Los sitios web modernos a menudo dependen de muchos recursos: imágenes, fuentes, hojas de estilo, scripts, videos incrustados, etc. Estos deben manejarse con cuidado para asegurarse de que no ralenticen el tiempo de carga de la página.
Por ejemplo
Las imágenes son una consideración importante. Una imagen grande que no está optimizada puede aumentar significativamente el tiempo de carga de la página. Además, incrustar videos directamente en la página puede tener el mismo efecto. En cambio, considera usar enlaces a servicios de alojamiento de videos como YouTube o Vimeo para manejar la carga y reproducción de videos de manera más eficiente.
Conclusiones
El rendimiento de WordPress es un aspecto crucial para la gestión exitosa de un sitio web. Monitorear el rendimiento y optimizarlo de manera efectiva puede aumentar los ingresos por anuncios, mejorar la experiencia del usuario y garantizar la disponibilidad constante en línea. Identificar y corregir los cuellos de botella más comunes, como problemas de estructura de datos, algoritmos ineficientes, solicitudes inadecuadas y falta de caché, son pasos importantes para lograr un sitio web de alto rendimiento.
En Grumft, ofrecemos soluciones de programación exclusivas para editores, desarrolladores de aplicaciones y anunciantes. Si eres un socio de anuncios, te invitamos a explorar nuestras herramientas y servicios diseñados para optimizar tus operaciones en línea.
¿Estás listo para llevar tu sitio web de WordPress al siguiente nivel de rendimiento? ¡No dudes en ponerte en contacto con nosotros y descubrir cómo Grumft puede ayudarte!
