Inferencias
Análisis de gráficos de cascada
La optimización del rendimiento requiere inferencias. Nunca se identificarán todas las oportunidades de optimización con una prueba de rendimiento de PageSpeed, independientemente de si se utiliza la mejor prueba de rendimiento del mercado o no.
Simplemente no hay forma de que una herramienta externa identifique los problemas del backend, y actualmente ninguna de ellas identifica todos los problemas del frontend. Por lo tanto, es necesario identificar los problemas basándose en información no explícitamente identificada en los informes de PageSpeed. Esto requiere que se extraigan estas conclusiones mediante la interpretación del diagrama de cascada de solicitudes de prueba de PageSpeed.
El siguiente ejemplo contiene algunas de las inferencias que se pueden hacer al revisar un gráfico de cascada.
Incluso los sitios bien optimizados pueden tener muchas oportunidades de mejora
Caso práctico de ThemeIsle
Algunos sitios están a punto de alcanzar un rendimiento perfecto, pero cuentan con optimizaciones fáciles de implementar que dispararían su puntuación a 90-100 con solo unos ajustes sencillos. Este es un excelente ejemplo de un sitio que ya está entre el 85 % y el 90 % del camino hacia la optimización completa, según su informe de PageSpeed.
Se pueden extraer muchísimas conclusiones del gráfico de cascada anterior. En la captura de pantalla superior solo se muestran 16 solicitudes; algunos sitios pueden tener más de cien. Ninguna de estas solicitudes se advertirá explícitamente en un informe de PageSpeed; debe extraer estas conclusiones mediante su propio análisis del informe.
Iconos
Fuente impresionante
La biblioteca de iconos de Font Awesome está en uso y se están cargando dos archivos de fuentes woff2 independientes para Font Awesome, con pesos de 400 y 900 (observe los valores en el nombre del archivo). Estos archivos están precargados, lo que los obliga a aparecer al principio del árbol de solicitudes.
Sus tamaños de archivo son de 13,4 kb y 77,7 kb respectivamente, por lo que el sitio carga un total de 91,4 kb de fuentes de iconos. Esto representa un gran problema y tendrá un impacto considerable en una prueba de velocidad. Estas dos solicitudes deben eliminarse si es posible, y los iconos deben reemplazarse con pequeños archivos SVG individuales. Incluso en páginas con uno o dos iconos, muchos plugins y temas utilizan toda la biblioteca de fuentes con todos los iconos (posiblemente miles), sin utilizarlos.
A veces, Font Awesome tiene un interruptor en los complementos y temas, a veces no.
Y esta es sólo una conclusión que se puede extraer del gráfico de cascada.
SVG individual de Twitter
La biblioteca Font Awesome está en uso, pero también se está cargando un icono SVG de Twitter. Esto es completamente innecesario, ya que las bibliotecas Font Awesome ya incluyen un icono de Twitter. Se debe hacer una de dos cosas: reemplazar todos los iconos con SVG individuales (práctica recomendada) o usar el icono de Twitter de la biblioteca Font Awesome (preferible cuando Font Awesome no se puede eliminar) para eliminar una solicitud innecesaria.
Imágenes no optimizadas
Las imágenes no se cargan de forma diferida
Se están cargando 9 imágenes en el árbol de solicitudes, lo cual, de entrada, es el problema más evidente. En primer lugar, solo una de estas imágenes se encuentra en la ventana gráfica (la foto del autor). Ninguna de las fotos que están fuera de la ventana gráfica se carga de forma diferida, lo que significa que se descarga una gran cantidad de peso de página innecesario en el renderizado inicial, lo que afecta negativamente a todas las métricas, pero tiene un impacto más significativo en las puntuaciones de LCP y CLS.
Las imágenes se pueden comprimir aún más
En segundo lugar, muchas de las imágenes son grandes y se pueden comprimir aún más, preferiblemente manualmente si es posible.
Tamaños de imagen
Hay varios tamaños de imagen que se pueden identificar a partir de los 9 nombres de archivo de solicitudes de imagen: 772×250, 1024×683, 1024×512 y 1024×736.
Esto indica varias cosas. Los tamaños de imagen son muy inconsistentes; se utilizan cuatro tamaños de imagen diferentes en la página. Cuanto menor sea el tamaño de la imagen, menor será el peso del archivo, lo que reducirá el impacto en el rendimiento.
Es posible que sea posible cambiar el tamaño de algunas de estas imágenes mientras se mantiene la calidad visual en dispositivos móviles (se pueden establecer resoluciones y puntos de interrupción específicos con complementos de cambio de tamaño de imagen y conjunto SRC), lo que reducirá aún más el tamaño de sus archivos.
Hay una advertencia explícita en el informe sobre los tamaños de las imágenes, pero se puede obtener aún más información simplemente inspeccionando los nombres de los archivos.
Formatos de archivo
Se pueden identificar dos formatos de archivo para las 9 imágenes que se cargan en la cascada: jpg y png. El tamaño de las imágenes se puede reducir aún más, más allá del simple cambio de tamaño y la compresión, si se utilizan formatos de última generación como AVIF y WebP en navegadores más recientes, mientras que los archivos jpg y png se siguen utilizando en navegadores antiguos no compatibles como alternativa.
Documento HTML inflado
Un problema con las pruebas de rendimiento es que el umbral para la advertencia de documento HTML grande es demasiado alto. El umbral adecuado para el peso de un documento HTML grande debería ser de 50 kb; cualquier valor superior se considera grande y tiene un efecto notablemente negativo en el rendimiento.
Basándonos en la solicitud principal de la página «blog» (el HTML raíz de la página), podemos ver que el peso del HTML es de 86,0 kb, lo que supera el límite máximo de 50 kb. El peso del documento HTML de un sitio debe reducirse al máximo para obtener las mayores mejoras de rendimiento.
Complemento de caché utilizado
Cohete WP
Debido a que los archivos CSS se han incorporado mediante una función de eliminación de CSS no utilizada y todo el javascript se ha retrasado (probable) o se ha incorporado (poco probable), debido a que no hay archivos javascript cargándose en el árbol de solicitud, el complemento de optimización no se puede identificar analizando las URL en el árbol de solicitud.
En su lugar, se debe visualizar el cuerpo HTML. Al abrirlo, queda claro que WP Rocket está en uso, ya que se hace referencia a él varias veces (» nowprocket» ).
Aunque no se recomienda WP Rocket, ya que generalmente se obtienen mejores resultados con Flyingpress, su implementación funciona perfectamente y no se deben realizar cambios a menos que surjan problemas al realizar optimizaciones adicionales. WP Rocket, con todas sus deficiencias, sigue siendo uno de los plugins de caché más eficaces.
CDN
El sitio utiliza Cloudflare como CDN y hay un acierto en el caché (lo que significa que el archivo se sirve desde el caché correctamente) para algunos archivos (servidos desde el caché de Cloudflare).
Brótli
Brotli está en uso.
Componentes de la hinchazón del documento
Debug Bear desglosa los componentes del documento HTML y muestra su tamaño. El 28,91% del peso del documento HTML proviene de CSS en línea (estilo), el 12,79% proviene de JavaScript en línea (script) y el 9,93% proviene de SVG en línea (ruta).
Los estilos CSS en línea tienen el mayor impacto en el rendimiento; 26,6 KB de estilos CSS en línea es excesivo.
11,1 KB de JavaScript también tienen un impacto significativo en el rendimiento.
Incluir demasiados SVG en línea también puede tener un impacto negativo. La inserción debe usarse con moderación y solo para recursos críticos.
Necesitará examinar el subcontenido de estos elementos y determinar su origen; luego, podrá optimizarlo. Esto requiere inspeccionar manualmente el árbol HTML en Debug Bear.
Llamadas externas de terceros
Hay 9 solicitudes de archivos desde el dominio host.
En la parte inferior de la cascada hay 6 solicitudes a dominios de terceros: 2 a use.typekit.net (fuentes) y 4 a ps.w.org (imágenes). Las llamadas a TypeKit son inevitables y deben realizarse a menos que las fuentes se puedan alojar localmente. Por lo tanto, si son necesarias, deben configurarse para preconectarse al dominio de terceros (use.typekit.net) y precargar el recurso. El atributo preload está configurado correctamente para las solicitudes de TypeKit; sin embargo, el atributo preconnect no lo está y debe añadirse.
Las 4 llamadas a ps.w.org son imágenes que deben reemplazarse con copias alojadas localmente.
La cantidad de solicitudes es baja
Se llaman muy pocos recursos en el árbol de solicitudes (23 recursos + el HTML raíz, 14 recursos mostrados en el árbol no expandido de la captura de pantalla). Esto indica que el sitio está bien optimizado.
Cualquier valor por debajo de 40 está en el punto óptimo.
Prioridad de obtención de recursos
Dos archivos tienen el atributo de prioridad de obtención establecido en «alta»: logo.png y best-wordpress-image-optimizer.xxx.png. Hay dos solicitudes más de alta prioridad al dominio use.typekit.net. Todas las demás solicitudes, excepto la prioridad de obtención del documento HTML raíz, tienen la prioridad de obtención establecida en «baja». Este atributo de prioridad de obtención «baja» puede conservarse incluso cuando el archivo está configurado para precargarse; esto no afecta negativamente a la funcionalidad de precarga.
Demasiadas fuentes precargadas
Hay demasiados archivos de fuentes precargados. Se debe minimizar la cantidad de recursos precargados y usarlos solo para recursos críticos.
Se han eliminado los CSS no utilizados
No se están cargando archivos CSS en el árbol de solicitudes. Esto es positivo e indica que se ha activado la función Eliminar CSS no utilizados en un complemento de optimización o que el código necesario se ha insertado manualmente. Se han eliminado todos los CSS no utilizados y se han insertado los CSS críticos en el documento HTML. Los CSS se pueden marcar como optimizados sin problemas.
Sin solicitudes de Javascript
No hay solicitudes de archivos JavaScript. Esto es muy positivo, ya que indica que el sitio ha retrasado todo su JavaScript (en su caso, podría retrasarse sin problemas) o que es un sitio web estático. No se descarga ni ejecuta código JavaScript durante el renderizado inicial, lo que elimina por completo cualquier impacto en el rendimiento que el código JavaScript pudiera tener en el renderizado inicial de la página.
Las imágenes se sirven a través de HTTP/2
HTTP/3 está habilitado en themeisle.com; sin embargo, algunos recursos aún se sirven a través de HTTP/2. Los archivos de imagen también se sirven a través de HTTP/2, lo que afecta el rendimiento.
Evita cadenas de redireccionamiento
No hay redirección intermedia HTTP > HTTPS > HTTPS://WWW .
LCP (Logotipo) está precargado
La imagen LCP está precargada correctamente.
Cambio de diseño
La puntuación CLS (Layout Shift) indica que los atributos de alto y ancho no se han aplicado a las imágenes.
Un TTFB bajo indica una base de datos optimizada y de baja carga
Un TTFB bajo indica que el backend de la base de datos está bien optimizado y presenta una carga excesiva. Un TTFB alto suele indicar una base de datos sobrecargada, un VPS/alojamiento con poca RAM o CPU débil, o una implementación de MySQL mal configurada.
Un tiempo de CPU bajo indica un Javascript optimizado y una base de datos optimizada
El tiempo de evaluación de la CPU proviene principalmente de JavaScript. Dado que todo el JavaScript crítico se ha integrado (sin archivos JS que se cargan en el árbol de solicitudes), el JavaScript integrado en el documento HTML es mínimo y está bien optimizado. Es probable que la base de datos esté bien optimizada, ya que una base de datos deficiente puede tener un impacto significativo en el rendimiento, tanto en el tiempo de CPU como en el tiempo total de ejecución (TTFB).
No se utilizan iframes
No existen llamadas de terceros para Iframes.
TLS 1.3 está en uso
TLS 1.3 (SSL) está habilitado en el dominio, que actualmente es la versión más nueva y de mayor rendimiento de TLS disponible.
Más de la mitad del peso de la página actual se puede eliminar de la representación inicial
Implementar una solución funcional de carga diferida reduciría automáticamente a la mitad el peso de la página. Tras implementar todas las sugerencias anteriores, el peso de la página podría reducirse aproximadamente tres veces, de 1,16 MB a aproximadamente 400-450 kb. Una reducción de 700 kb resultaría en mejoras significativas de rendimiento.
Caso práctico 2: Elementor.com
Alivio cómico
Has llegado hasta aquí en la guía, ¿quién está listo para un poco de alivio cómico?
https://www.debugbear.com/test/website-speed/jl9XSI2N/overview
Aquí hay algunas capturas de pantalla de informes de velocidad de página para Elementor.com.
Y aquí está el informe de Pagespeed para un sitio de Pagespeed Optimization Services desarrollado y optimizado personalmente (¡actualmente no está activo porque aún está en desarrollo!) creado con Elementor:
Análisis
Optimizador visual de sitios web
El segundo elemento de la cascada muestra claramente que utilizan Visual Website Optimizer para el análisis de clientes. Para optimizar VWO, el código JavaScript debe retrasarse con una función de retardo en un complemento de optimización.
Elementor.com utiliza un plugin de geolocalización desarrollado por ellos mismos, llamado «geo-loader». Podemos deducir que lo utilizan para identificar la ubicación de los clientes, y estos datos se introducen en una plataforma de análisis externa o en una desarrollada a medida.
Numerador de Jquery
Se está cargando el Numerador de jQuery, que se utiliza para animar números. Este archivo js suele retrasarse para minimizar su impacto en el rendimiento, a menos que el elemento animado se encuentre en la parte superior de la página y la animación se necesite inmediatamente sin interacción del usuario.
Inscripción al boletín informativo
Utilizan un plugin de suscripción al boletín desarrollado a medida. Es casi seguro que se puede retrasar para minimizar el impacto en el rendimiento sin afectar la funcionalidad, ya que no es necesario hasta que el usuario interactúe con el formulario vinculado a la funcionalidad.
WP Polyfill
El archivo wp-polyfill.min.js de WP Core se está cargando, y puede descargarse de forma segura con Asset Cleanup/Perfmatters o un plugin de descarga selectiva de recursos, o bien retrasarse. La clave para saber que se trata de un archivo cargado desde WP Core (el núcleo de WordPress) es que la ruta del archivo contiene «wp-includes», donde se almacenan todos los archivos de WP Core.
Polyfill sirve como renderizado de respaldo para navegadores antiguos no compatibles (Internet Explorer), lo cual no es necesario.
Tiempo de ejecución del regenerador
Otro archivo de WP Core que suele ser innecesario. Elementor no necesita este archivo para ninguna funcionalidad y se puede retrasar o deshabilitar sin problemas. Algunos plugins dependen de este archivo (raramente), así que prueba tu sitio después de deshabilitarlo o retrasarlo; sin embargo, en la gran mayoría de los casos, debería poder eliminarse sin problemas.
Mirage de Cloudflare
Hay varias conclusiones que podemos extraer de esta solicitud. En primer lugar, Elementor.com utiliza Cloudflare como su CDN. En segundo lugar, utiliza la función de optimización de imágenes de Mirage . Recomiendo evitar esto, ya que la optimización de imágenes debe realizarse localmente en el servidor web, y una función de CDN como esta es un parche, no una solución definitiva. Si realmente se desea usar Mirage, debería utilizarse como complemento después de que las imágenes ya se hayan optimizado manualmente o con un plugin de optimización de imágenes. No sustituye a la optimización de imágenes.
Elementor.com ha cometido el error de confiar completamente en Mirage para la optimización de imágenes, por eso tiene muchas imágenes grandes e infladas en la página.
Imágenes cargadas JS
El archivo JavaScript imagesloaded es otro archivo JavaScript de WP Core que normalmente se puede retrasar sin problemas. Suele cargarse por defecto. A veces, este archivo no es necesario en el renderizado inicial, incluso cuando las imágenes están en la ventana gráfica o en la parte superior del pliegue al cargar la página. Sin embargo, los controles deslizantes pueden depender de este archivo, así que asegúrese de probar primero con retraso o incluso descargándolo en un sitio de prueba antes de enviar el cambio a producción.
i18n
Otro archivo de WP Core que se carga por defecto en todos los sitios de WordPress. Este archivo se utiliza para la función de traducción. Si su sitio no es multilingüe, este archivo es innecesario y puede descargarse o retrasarse sin problemas. Recibirá un error en la consola de su navegador si se descarga o retrasa , pero este error se puede ignorar y no afecta al rendimiento ni a la funcionalidad.
Hooks.min.js
Otro archivo de WP Core que se carga por defecto. Muchos plugins y temas dependen de este archivo .js para su funcionalidad, pero la mayoría no requiere que se cargue inmediatamente, lo que significa que se puede retrasar sin problemas en la mayoría de los casos. No recomiendo descargar este archivo; en su lugar, recomiendo retrasarlo.
Administrador de etiquetas de Google
Elementor utiliza Google Tag Manager para implementar el seguimiento de análisis. Este archivo se puede retrasar, lo que mitigará su impacto en el rendimiento. Sin embargo, tenga en cuenta que retrasar Tag Manager distorsionará ligeramente sus análisis, especialmente las estadísticas de tasa de rebote. Es una compensación que vale la pena, ya que el objetivo real es aumentar el tráfico, las conversiones y las ventas. Los datos por el mero hecho de obtenerlos ignoran los objetivos reales de un sitio web.
Captcha
Sin expandir esta solicitud, no resulta obvio de inmediato que se trata de un captcha, aunque la primera captura de pantalla hace referencia a google.com a la derecha. Sin embargo, al expandirla, podemos ver la palabra «recaptcha» en la URL, lo que indica directamente que se está utilizando un captcha de Google.
Los captchas consumen mucho rendimiento y añaden bastante peso a la página. Se recomienda evitarlos por completo siempre que sea posible e implementar una solución diferente. Dado que el sitio ya utiliza Cloudflare, si realmente se necesita un captcha, se debe usar el de Cloudflare. Existen soluciones alternativas a los captchas para formularios y bots, que se detallan más adelante en la guía.
ScrollTrigger.min.js
Podemos inferir varias cosas a partir de esta solicitud. Una es que la funcionalidad está relacionada con las acciones que se activan al desplazarse. La segunda es que se trata de una solicitud de terceros a un dominio externo, en este caso a una CDN.
Este archivo JavaScript es triplemente problemático. Añade 17,2 kb de peso a la página, lo cual ya es considerable para un archivo JavaScript y puede causar un tiempo de procesamiento adicional considerable, incluso con un peso de archivo relativamente pequeño.
En segundo lugar, debido a que realiza una solicitud externa a un dominio separado, introduce una latencia de red de ida y vuelta debido a la solicitud HTTP.
En tercer lugar, todos los archivos javascript bloquean el analizador, lo que significa que la métrica del tiempo de bloqueo (a veces también denominada TBT en algunas pruebas de velocidad) aumentará, lo que también perjudica las puntuaciones de PageSpeed.
Este archivo debe eliminarse por completo si es posible y, si es necesario, debe retrasarse si hacerlo no interrumpe la funcionalidad prevista.
TextPlugin.min.js
Este archivo JavaScript está relacionado con el texto, posiblemente una animación o la inserción de una fuente personalizada. Es posible que este plugin se pueda retrasar sin problemas, pero es necesario probarlo en el entorno de pruebas. Además, se sirve desde un dominio CDN de terceros, lo que afecta negativamente al rendimiento.
gsap.min.js
Este es un archivo JavaScript relacionado con la animación, distribuido por una CDN de terceros. No se sirve desde el dominio local (elementor.com). La llamada HTTP de terceros es una práctica inadecuada y afecta negativamente el rendimiento del sitio.
Si la animación se encuentra por debajo del pliegue, debería ser seguro retrasarla. Si se encuentra por encima del pliegue y se retrasa, es posible que la animación no se cargue o no se reproduzca hasta que se haya interactuado con la página de alguna manera.
IvarHeadline-Negrita.woff2
Ivar Headline es una fuente personalizada en formato WOFF2, y elementor.com utiliza la versión en negrita. WOFF2 es la mejor opción para archivos de fuentes, ya que están precomprimidos, lo que reduce su tamaño.
K6z9mXg.woff2
La fuente utilizada no se puede identificar por el nombre del archivo. Aquí se observa que elementor.com utiliza una combinación de fuentes alojadas localmente, así como fuentes de Google, llamadas desde la CDN de Google desde fonts.gstatic.com. Todas las fuentes deben estar alojadas localmente, ya sea mediante carga manual o mediante un complemento automático como Yabe Webfont u OMGF (que se explica más adelante en la guía).
Archivos de vídeo WebM
Estos son los archivos más problemáticos del sitio web de Elementor. En total, estos tres vídeos pesan 2,5 MB, lo que afecta considerablemente la velocidad de la página. Estos archivos no aparecen en la parte superior de la página en la versión de escritorio, y solo uno de ellos aparece en la parte superior de la página en el móvil. Esto significa que en la versión de escritorio, los tres archivos WebM deberían cargarse de forma diferida, y dos de ellos deberían cargarse de forma diferida en el móvil. El sitio de Elementor no tiene habilitada ninguna solución de carga diferida de vídeos.
El uso del formato WebM es bueno ya que el formato comprime los archivos de imagen y generalmente tiene un mejor rendimiento que otros formatos, sin embargo, estos videos se pueden comprimir manualmente aún más para reducir el tamaño del archivo más allá de simplemente convertirlos a WebM (la sección de optimización de video está más abajo).
GIF del Optimizador visual de sitios web
Visual Website Optimizer (la herramienta de análisis mencionada más adelante en este caso práctico) está cargando un archivo GIF desde su dominio, que es una llamada HTTP de terceros. Aunque el tamaño del archivo es insignificante (144 bytes), la llamada externa seguirá teniendo un impacto negativo considerable en el rendimiento.
Script EDRV del Optimizador Visual de Sitios Web
Otra llamada externa a un script, enviada desde la CDN de Visual Website Optimizer. Debería retrasarse para minimizar su impacto en el rendimiento.
Administrador de etiquetas de Google
El sitio web de Elementor utiliza una interesante implementación de administrador de etiquetas. Su script de administrador de etiquetas se sirve localmente (práctica recomendada), pero en lugar de desde el dominio raíz local, se sirve desde un subdominio (gtm.elementor.com). La decisión de servirlo desde un subdominio podría tener varias razones; para comprender la lógica de esta decisión, sería necesario revisar la configuración de su backend.
Ley de cookies
El banner de cookies del sitio de Elementor se implementa con un servicio llamado «Cookie Law». Este script no se sirve desde el dominio local, sino que se llama desde la CDN de Cookie Law. Es un archivo JavaScript relativamente pequeño. El banner debería retrasarse si es aceptable que no se muestre hasta la interacción del usuario (esto es aceptable en la mayoría de los casos, a menos que el propietario del sitio solicite la exclusión del archivo para que aparezca inmediatamente).
Píxel de Reddit
Esto es poco común, ya que no muchos sitios lo usan, pero Elementor.com utiliza un píxel de seguimiento de Reddit Analytics proveniente del dominio CDN redditstatic. Este archivo debería retrasarse para eliminar su impacto en el rendimiento, pero, como con cualquier otro script de análisis, retrasarlo distorsionará las métricas de tasa de rebote.
Beacon.min.js
El archivo beacon.min.js es un archivo de análisis utilizado por Cloudflare. A menos que su sitio web necesite Cloudflare Analytics, debe desactivarlo. Dado que el archivo se carga a través de la propia CDN de Cloudflare, no se puede retrasar con un plugin de retardo de JavaScript de WordPress, ya que se sirve en la capa de red y no a través de un plugin del sitio. La única forma de mitigar el impacto en el rendimiento es desactivar por completo el análisis de Beacon de Cloudflare.
Continuará
Quedan unos 110 archivos más en la cascada para que elementor.com los agregue a este estudio de caso.
Más allá de los gráficos en cascada
Construido con
Algunos complementos y servicios (por ejemplo, los de análisis) no se pueden identificar desde el árbol de cascada. Para identificarlos, BuiltWith es una herramienta fantástica que permite su identificación.
BuiltWith puede identificar plugins comunes explícitamente. Aquí podemos ver que Yoast, ConvertBox, Google Tag Manager para WordPress y WP Rocket se identifican directamente. TypeKit también se utiliza.
Conceptos erróneos comunes
Las puntuaciones de PageSpeed Lab no importan
Un error común es creer que las puntuaciones de laboratorio de Google PageSpeed Insights no son relevantes. Son las métricas que se optimizan, ya que cualquier prueba de velocidad solo mide datos de laboratorio sintéticos, simulados en condiciones controladas. Utilizan una versión simulada del teléfono con el mínimo común denominador, con hardware deficiente y una conexión con ancho de banda limitado. Las pruebas están diseñadas para simular el peor escenario posible cuando un usuario carga un sitio web.
Estas puntuaciones son muy precisas en ese contexto. Las mejoras en las puntuaciones de laboratorio mediante la optimización se traducirán directamente en mejoras en el rendimiento en el mundo real.
Es imposible crear un sitio web de alto rendimiento con un generador de páginas
Un dicho común es que hay que evitar por completo los creadores de páginas porque son pesados y lentos. Esto es solo una verdad a medias. Cualquier creador de páginas será lento sin optimización. Oxygen y Bricks están relativamente bien optimizados de fábrica, pero si se colocan imágenes grandes en la parte superior de la página, el LCP y el índice de velocidad seguirán teniendo una baja puntuación. Todos los creadores de páginas pueden beneficiarse del almacenamiento en caché, el almacenamiento en caché de la base de datos, la optimización de CSS, etc., incluidos Bricks y Oxygen.
Una vez optimizado, un constructor bien codificado, o incluso uno mal codificado, puede lograr fácilmente puntuaciones superiores a 90 en una prueba de Mobile PageSpeed Insights.
El almacenamiento en caché de páginas a nivel de servidor es un sustituto de los complementos de almacenamiento en caché de WordPress
Este es un error muy común e incorrecto. El almacenamiento en caché de páginas HTML a nivel de WordPress con plugins es complementario al almacenamiento en caché de páginas HTML a nivel de servidor, y deben usarse simultáneamente.
Flujo de trabajo e interacción
Manejo de solicitudes iniciales
Cuando un usuario solicita una página por primera vez, la solicitud se envía a través del servidor web (p. ej., NGINX, Apache). Si la caché del servidor (p. ej., Varnish, NGINX FastCGI) no tiene una versión en caché de la página, reenvía la solicitud a la aplicación (WordPress).
Almacenamiento en caché de páginas a nivel de WordPress
El complemento de almacenamiento en caché de WordPress (por ejemplo, Flyingpress, W3 Total Cache) verifica si tiene una versión HTML estática en caché de la página solicitada.
Si existe una versión en caché, se muestra el contenido HTML estático almacenado en caché. De lo contrario, WordPress genera la página dinámicamente y el plugin de caché guarda una versión HTML estática para futuras solicitudes.
Almacenamiento en caché a nivel de servidor
Luego, el contenido HTML estático generado o almacenado en caché de WordPress se envía de vuelta al servidor web.
La caché a nivel de servidor ahora puede almacenar en caché este contenido HTML estático para una entrega aún más rápida en solicitudes posteriores.
Secuencia de capas de almacenamiento en caché
Primera solicitud
User request → Web server (server-level cache miss) → WordPress (WordPress-level cache miss) → WordPress dynamically generates page → WordPress caching plugin saves static HTML → Server receives static HTML → Server-level cache saves static HTML.
Solicitudes posteriores
User request → Web server (server-level cache hit) → Static HTML is served from server-level cache.
Si falla la caché a nivel de servidor
User request → Web server (server-level cache miss) → WordPress (WordPress-level cache hit) → WordPress serves cached static HTML → Server receives and caches static HTML.
Resumen de la interacción
Caché a nivel de servidor
Opera primero, almacenando en caché toda la respuesta a nivel de servidor web para una entrega muy rápida. Gestiona la solicitud antes de que llegue a WordPress.
Caché a nivel de WordPress
Actúa como caché secundaria que gestiona las solicitudes si falla la caché a nivel de servidor. Genera o sirve HTML estático desde la aplicación WordPress.
La superposición de cachés crea un sistema de almacenamiento en caché de varios niveles
El caché a nivel de servidor (por ejemplo, NGINX, Varnish) actúa como primera línea de defensa, almacenando en caché y sirviendo HTML estático rápidamente sin involucrar PHP o WordPress.
El caché a nivel de WordPress (por ejemplo, Flyingpress, W3 Total Cache) proporciona una capa secundaria, lo que garantiza que incluso si falla el caché a nivel de servidor, se puede servir una versión en caché dentro de WordPress sin tener que regenerar la página dinámicamente.
¿Por qué son necesarios los complementos de almacenamiento en caché de páginas?
Generación de HTML optimizada
Los plugins de caché de WordPress suelen hacer más que simplemente almacenar en caché. También optimizan la salida HTML eliminando caracteres, comentarios y espacios innecesarios, lo que reduce el tamaño total del documento HTML.
Control granular
Los plugins de caché de WordPress permiten un control más preciso sobre qué se almacena en caché y cómo. Esto puede incluir reglas específicas para usuarios conectados, páginas de comercio electrónico u otro contenido dinámico que la caché a nivel de servidor podría no gestionar con la misma eficiencia.
Carga de backend reducida
Mientras que el almacenamiento en caché a nivel de servidor reduce la carga del servidor web, los plugins de almacenamiento en caché de WordPress reducen la carga de la propia aplicación. Esto se traduce en menos consultas a la base de datos y ejecuciones de PHP, lo que se traduce en tiempos de respuesta más rápidos y mejores resultados.
TTFB mejorado (tiempo hasta el primer byte)
Los plugins de caché de WordPress pueden mejorar el TTFB al servir contenido HTML estático directamente desde la capa de WordPress. Esta respuesta inmediata ayuda a obtener mejores puntuaciones de PageSpeed.
Calentamiento de caché
Algunos complementos de almacenamiento en caché proporcionan una función para prealmacenar en caché o «calentar» las páginas, lo que garantiza que los visitantes siempre obtengan la respuesta más rápida posible.
Ejemplo práctico
Incluso con el almacenamiento en caché a nivel de servidor habilitado, considere las siguientes mejoras que podría aportar un complemento de almacenamiento en caché de WordPress
Antes de instalar el complemento
La caché a nivel de servidor está habilitada, pero la generación inicial de HTML aún podría implicar consultas innecesarias a la base de datos y una salida HTML no optimizada. Los resultados de PageSpeed son buenos, pero no óptimos.
Después de la instalación del complemento
El complemento de almacenamiento en caché de WordPress comienza a servir una versión HTML más limpia y optimizada de la página.
Optimizaciones adicionales como minimización, compresión de imágenes y reducción de solicitudes HTTP mejoran aún más el rendimiento.
El efecto combinado da como resultado tiempos de carga de página más bajos, TTFB mejorado y puntuaciones PageSpeed más altas.
La mejora inmediata en las puntuaciones de PageSpeed tras añadir un plugin de caché de WordPress, incluso con la caché a nivel de servidor habilitada, se debe principalmente a las optimizaciones adicionales y las mejoras de eficiencia que el plugin aporta a la generación de HTML y al manejo general de recursos. Estas mejoras van más allá del simple almacenamiento en caché y contribuyen significativamente a mejorar las métricas de rendimiento.
Un DOM inflado afectará el rendimiento
Esta es otra verdad a medias. Lo cierto es que un DOM inflado, junto con un documento HTML de gran tamaño, afectará significativamente la velocidad de carga de la página. Un DOM puede ser grande si el peso del documento es bajo sin afectar significativamente el rendimiento.
Elementor, por ejemplo, añade muchos elementos DOM, lo cual es una lástima, ya que dificulta la personalización de elementos con CSS personalizado. Sin embargo, una vez optimizado, el impacto en el rendimiento del tamaño excesivo del DOM se mitiga. El factor más importante para la optimización siempre es el peso de la página/recurso.
Idealmente, el tamaño del DOM de una página debería ser inferior a 1000 elementos para minimizar el impacto en el rendimiento. Una vez que el tamaño del DOM supere este límite, se observarán caídas mínimas en la velocidad de la página. Una página con 1500 o incluso 2000 elementos puede renderizarse rápidamente si el tamaño del documento HTML es bajo. Si se superan los 2000 elementos, se empezarán a observar caídas notables (aunque relativamente leves) en la velocidad de la página, incluso con un documento HTML más pequeño.
Los sitios de Pagebuilder no pueden manejar una alta carga de servidor en sitios con mucho tráfico
Esto también es una falacia parcial. Un sitio web creado con un constructor de páginas sin optimizar colapsará fácilmente bajo la presión del tráfico excesivo. El servidor de base de datos (MySQL o cualquier otra variante de base de datos, como MariaDB) se verá rápidamente saturado por una avalancha de consultas, incluso con almacenamiento en caché de objetos.
Para mitigar el impacto de estas consultas, asegúrese de que todas las opciones de carga automática configurables como «no» estén configuradas correctamente. Optimizar el CSS, Javascript y cualquier otro archivo optimizable de sus creadores de páginas reducirá las consultas a la base de datos, lo que a su vez reducirá la carga en su servidor. Un sitio optimizado con Elementor puede gestionar fácilmente 100 000 usuarios simultáneos en un VPS de gama media, y eso podría escalar a millones de usuarios simultáneos.
Elementor puede funcionar tan bien como Gutenberg cuando está optimizado adecuadamente.
Los encabezados y pies de página deben estar codificados en CSS en lugar de en su constructor para obtener el mejor rendimiento
Si bien codificar encabezados y pies de página en CSS puede mejorar el rendimiento, el impacto es mínimo, en el mejor de los casos, al usar la función Eliminar CSS no utilizado con plugins de optimización. Muchos creadores de páginas generan archivos CSS voluminosos para muchos elementos, incluidos encabezados y pies de página, lo cual se puede mitigar con un simple interruptor.
Advertencia: algunos creadores de páginas obtendrán mayores beneficios al codificar el encabezado y el pie de página que otros.
PageSpeed solo afecta al SEO
Si bien la principal motivación para mejorar la velocidad de una página suele ser un mejor posicionamiento SEO, un factor que a menudo se pasa por alto es la retención de clientes. Una mayor retención de visitantes puede generar un aumento sustancial de los ingresos, además de simplemente aumentar el número total de visitantes y reducir la tasa de rebote. Por ejemplo, reducir la tasa de rebote del 60 % al 30 % puede resultar en ingresos/conversiones significativamente mayores, más ventas y mejoras en acciones como el llenado de formularios de contacto.
Los beneficios de una mayor participación y retención de visitantes se extienden más allá de simplemente atraer más visitantes: no se puede exagerar la importancia de retenerlos.
Las puntuaciones de PageSpeed no importan
Este es uno de los estribillos más absurdos que se pueden encontrar al hablar de PageSpeed. Las puntuaciones de PageSpeed son absolutamente importantes. Como se explicó en las secciones de Pruebas de Velocidad e Inferencias, las puntuaciones de PageSpeed son una combinación de varias métricas que dan como resultado una puntuación compuesta única sobre 100.
El valor diagnóstico de las puntuaciones totales mide el progreso hacia las métricas de optimización deseadas, pero la puntuación en sí no proporciona información útil para el diagnóstico. Las submétricas en las que se basa la puntuación compuesta de PageSpeed (TTFB, INFP, INTP, CLS, Índice de Velocidad, LCP, FCP, Tiempo de Bloqueo (TBT)) son las métricas útiles y tienen significados específicos, como se explicó anteriormente. Estas métricas son cuantificables y ofrecen indicaciones claras de su relevancia para la experiencia del usuario en el sitio web.
Cuando alguien dice que estas métricas no son importantes, esto indica una incomprensión subyacente de lo que significan estas métricas.
Se incluyen aquí nuevamente sus definiciones:
Artículo de Escape Creative
Esta página tiene una descripción general decente de las métricas y lo que significan.
Artículo de Corelogix
Otro artículo útil con explicaciones bastante detalladas de varias métricas de Core Web Vitals y sus definiciones.
Documentación de Core Web Vitals de Google
Documentación y definiciones de Core Web Vitals directamente de Google.
Los complementos de seguridad como Wordfence son un requisito
Cierto a medias. Los archivos solo deberían escanearse con cierta regularidad en un sitio de prueba. Wordfence tiene un efecto negativo significativo en el rendimiento del sitio. Un sitio web bien optimizado puede perder entre 10 y 15 puntos en una prueba de PageSpeed móvil con solo activar Wordfence.
El rendimiento de su servidor de prueba es irrelevante para los usuarios y no tendrá impacto en las conversiones.
En lugar de utilizar la funcionalidad de firewall de Wordfence, se recomienda un complemento de firewall de nivel de aplicación liviano (WordPress) (Ninja Firewall y BBQ Firewall son opciones relativamente buenas).
En lugar de depender únicamente de plugins de firewall, se recomienda tener tres capas de firewall: una a nivel de WAF (Cloudflare, por ejemplo); una a nivel de servidor (como el firewall 8G/7G para Apache/NGINX); y, por último, una a nivel de aplicación para WordPress. WordPress debería ser la última línea de defensa; si los bots logran atravesar las dos primeras capas, ya existe un problema grave. Además, es muy recomendable añadir Patchstack.
Seguridad
Impacto en el rendimiento de las medidas de seguridad
Alta carga de CPU y presión excesiva de RAM
Una carga alta de CPU o una presión excesiva de RAM harán que su sitio funcione muy lentamente y en muchos casos pueden dejar fuera de servicio completamente su servidor temporalmente hasta que se haya solucionado (eliminado) la infección.
El impacto negativo del malware en el rendimiento
Una carga alta e inexplicable de la CPU o una presión excesiva de la RAM pueden indicar una infección de malware. Las medidas de seguridad son fundamentales para resolver problemas relacionados con el malware; sin embargo, no mejorarán el rendimiento de un sitio web, sino que solo evitarán efectos perjudiciales hasta alcanzar el rendimiento base actual.
Ejemplo: Un sitio web tiene una puntuación de 60 puntos sin carga adicional de CPU ni RAM antes de un incidente de seguridad, como una infección de malware o un ataque DDoS. Una vez que el sitio empieza a sufrir el ataque, la puntuación promedio baja a 30 puntos.
Remediar una infección de malware restaurará la puntuación del sitio a su valor inicial, es decir, 60 en este caso hipotético. Sin el malware, el rendimiento del sitio web no mejorará; solo se mitigarán los efectos negativos de la infección de malware, DDoS u otros tipos de ataque.
Impacto en el rendimiento de las mitigaciones
De hecho, las soluciones de seguridad y la mitigación implementadas para remediar el malware, así como los métodos de protección contra infecciones como firewalls y complementos de seguridad, pueden tener, y tendrán, un efecto negativo en el rendimiento base . Sin embargo, la compensación por prevenir este tipo de ataques con una pequeña pérdida de rendimiento puede valer la pena si su sitio web sufre ciberataques, especialmente ciberataques regulares.
Ataques de fuerza bruta
¿Es un artículo de WP?
https://www.isitwp.com/stop-brute-force-attacks-wordpress-website
Artículo básico que presenta algunos métodos para mitigar ataques de fuerza bruta.
Los ataques de fuerza bruta implican que recibes una cantidad excesiva de intentos de inicio de sesión, lo que puede causar una alta carga de CPU y saturar la RAM del servidor. Miles de intentos de inicio de sesión pueden ralentizar tu sitio web e incluso provocar un bloqueo. Esto puede afectar tu experiencia de usuario, lo que significa que los visitantes abandonarán tu sitio web, ya que no cargará lo suficientemente rápido al consumir todos los recursos del servidor.
Limitar intentos de inicio de sesión recargado (gratis)
Limit Login Attempts Reloaded funciona como un potente elemento disuasorio contra ataques de fuerza bruta. Restringe el número de intentos de inicio de sesión permitidos. Esto aplica no solo al método de inicio de sesión estándar, sino también a XMLRPC, WooCommerce y páginas de inicio de sesión personalizadas.
Deshabilitar XML-RPC
¿Por qué debería deshabilitar XML-RPC?
Los ataques DDoS (Denegación de Servicio Distribuido) se producen cuando un atacante sobrecarga un servidor web con tráfico de internet para impedir que otros usuarios accedan a sus sitios web y servicios en línea. Los atacantes utilizan la función PingBack para enviar pingbacks a numerosos sitios y, con XML-RPC, obtienen un número ilimitado de direcciones IP para distribuir los ataques DDoS.
Ataques de fuerza bruta
XML-RPC.php se utiliza para probar diferentes combinaciones de nombres de usuario y contraseñas. Esta vulnerabilidad les permite automatizar el ataque con un comando que introduce miles de combinaciones a la vez, evadiendo la seguridad de su sitio web y obteniendo acceso a él.
Cómo deshabilitar XML-RPC
Limpieza de activos (gratuita y profesional)
Asset Cleanup es un complemento multifunción muy recomendado que se centra principalmente en la desactivación selectiva de activos CSS y JS, así como en la capacidad de deshabilitar por completo la carga de complementos en páginas seleccionadas.
Asset Cleanup también tiene la funcionalidad de deshabilitar XML-RPC.
Deshabilitar XML-RPC de forma sencilla (gratuito)
La única función de Simple Disable XML-RPC es deshabilitar XML-RPC, con una considerable capacidad de configuración. Es muy ligero: el plugin pesa solo 10 kb.
Cortafuegos
Tipos de firewall
Los firewalls siempre tendrán un impacto negativo en el rendimiento de su sitio. La seguridad y el rendimiento son un equilibrio que debe considerarse/evaluarse al implementar diversas medidas de seguridad.
Diferencias entre los WAF y los firewalls de capa de red/servidor
Impacto en el rendimiento de los firewalls
Artículo del IJSTR
https://www.ijstr.org/final-print/mar2017/Impact-Of-Firewall-On-Network-Performance.pdf
Un análisis completo del impacto del rendimiento de los firewalls en el rendimiento del sitio web.
Impactos en el rendimiento de la red WAF
Aisnet
https://aisel.aisnet.org/cgi/viewcontent.cgi?article=1007&context=wisp2020
ResearchGate
Artículo de Fortinet
Cortafuegos de alto rendimiento a nivel de servidor
Cortafuegos 7G NGINX (gratuito)
https://perishablepress.com/7g-firewall-nginx
El firewall 7G de alto rendimiento de Jeff Starr para NGINX. La versión 8G para NGINX está actualmente en desarrollo.
Cortafuegos Apache 8G (gratis)
https://perishablepress.com/8g-firewall
Cortafuegos Apache 8G de Jeff Starr.
Firewalls de aplicaciones web (WAF) de alto rendimiento
Firewall de aplicaciones web
Un firewall de aplicaciones web (WAF), generalmente de una CDN, funciona en la capa de red para bloquear el tráfico malicioso antes de que llegue a su servidor web. Cloudflare cuenta con un WAF sólido, Microsoft tiene Front Door para Azure y existen muchos más. Esto permite un control mucho más granular y definiciones de la nube actualizadas periódicamente para detectar amenazas a medida que surgen.
Un WAF también le permitirá tener algunas características ingeniosas que le permitirán prohibir países de manera general para restringir el tráfico, lo que reducirá la carga del servidor (si su sitio es atacado regularmente) y los intentos de piratería.
BunkerWeb (Gratis)
https://github.com/bunkerity/bunkerweb
WAF a nivel de servidor gratuito, flexible y configurable.
NGINX App Protect WAF (gratis)
https://gigaom.com/report/high-performance-web-application-firewall-testing
En las pruebas de GigaOm, se descubrió que NGINX App Protect tenía mejor rendimiento que los tres WAF en la nube que probaron.
Guía de configuración
https://docs.nginx.com/nginx-app-protect-waf/v4/configuration-guide/configuration
Cloudflare WAF (Gratis y Pro)
https://www.cloudflare.com/application-services/products/waf
Un WAF de alto rendimiento desarrollado por Cloudflare. Como cualquier firewall, tiene un impacto negativo en el rendimiento, pero el de Cloudflare está relativamente bien optimizado. Se combina mejor con Argo de Cloudflare, así como con otras funciones de optimización del rendimiento de red y tráfico de Cloudflare.
Reglas de firewall de Cloudflare para proteger sitios web de WordPress
https://gridpane.com/blog/cloudflare-firewall-rules-for-securing-wordpress-websites
Errores de PHP
Los errores de PHP pueden tener efectos perjudiciales significativos sobre el rendimiento.
Administrador de registros de depuración (gratis)
El Administrador de Registros de Depuración puede habilitar múltiples tipos de registro automático, lo cual es una excelente manera de detectar errores de PHP y proporcionar información de diagnóstico para descubrirlos y corregirlos. La mayoría de los plugins y temas tienen errores de PHP, incluso leves, y cada error de PHP puede afectar negativamente al rendimiento.
Si tiene un código personalizado, Debug Log Manager puede ayudarle a identificar problemas con el código que ha escrito y, si tiene errores de PHP de complementos o temas, le brindará información clara para informar como un error al desarrollador para que pueda implementar una solución.
Monitor de consultas (gratis)
Query Monitor informa errores de PHP.
Complementos de seguridad
Artículo para principiantes de WP
Artículo muy básico que explica cómo utilizar un complemento de escáner de seguridad.
GOTMLS (Gratis)
Complemento antimalware ligero
Complementos que se deben evitar
Wordfence
No uses Wordfence en tu sitio web en producción. Es extremadamente voluminoso y perjudica mucho el rendimiento. Wordfence es una buena forma de analizar tu sitio en busca de malware, ¡pero úsalo solo en pruebas! Puedes obtener fácilmente funciones de firewall y escáner con otros plugins de mayor rendimiento.
Autenticación de dos factores
Dos factores (gratis)
Plugin oficial de inicio de sesión de 2 factores del equipo de desarrollo de WordPress. Ligero y con excelente soporte para cualquier problema.
Autenticación fluida (gratuita)
Complemento ligero de autenticación de dos factores
Cortafuegos para barbacoa (gratis)
Excelente firewall a nivel de aplicación de Jeff Starr. Se recomienda combinarlo con el firewall a nivel de servidor 8G y un WAF.
Bloquear bots maliciosos
Banhammer (Gratis)
Banhammer le brinda control total sobre quién y qué puede acceder a su sitio.
Encabezados de seguridad
Escáner de encabezados de seguridad (gratis)
Tu sitio debería obtener una A en securityheaders.com. ¡Es muy fácil de conseguir!
Seguridad de encabezados avanzada y HSTS WP (gratis)
Seguridad de encabezados avanzada y HSTS WP (gratis)
El proyecto Headers Security Advanced & HSTS WP implementa encabezados de respuesta HTTP que su sitio puede usar para aumentar la seguridad de su sitio web.
El complemento configurará automáticamente todas las mejores prácticas (no tiene que pensar en nada), estos encabezados de respuesta HTTP pueden evitar que los navegadores modernos se encuentren con vulnerabilidades fácilmente predecibles.
El proyecto Headers Security Advanced & HSTS WP quiere popularizar y aumentar el conocimiento y el uso de estos encabezados para todos los usuarios de WordPress.
Patchstack (Freemium)
Patchstack puede aplicar parches virtuales a plugins vulnerables incluso antes de que los desarrolladores los actualicen, lo que puede evitar que tu sitio web sea hackeado. Patchstack es una de las mejores empresas de análisis de vulnerabilidades y, con frecuencia, es la que encuentra vulnerabilidades de día cero. Muy recomendable.
Patchstack tiene un nivel gratuito, pero para obtener material realmente bueno y útil necesitas uno de los planes pagos.
Endurecer (Gratis)
Hardenize: Prueba completa de configuración del sitio web
Escanee su sitio para detectar problemas de seguridad comunes.
Sin scripts en línea inseguros (gratis)
Guía de fortalecimiento de servidores Linux
https://ivansalloum.com/comprehensive-linux-server-hardening-guide
Cumplimiento de SOC para WordPress
https://www.kevinleary.net/blog/soc-compliance-wordpress-websites
Imunify360 (Pago)
Una suite de seguridad muy completa. Ofrece muchas funciones ingeniosas que no he visto en otros proveedores de seguridad. Sin embargo, su interfaz, que parece de principios de los 2000, es un poco cutre.
Blog de Kevin Leary
https://www.kevinleary.net/blog/securing-a-wordpress-website
Registro de auditoría
Registro de actividad principal (gratuito)
CoreActivity Log es un plugin gratuito para monitorizar y registrar diversas actividades. Es altamente modular, con eventos registrados y controlados por múltiples componentes.
Actualmente, el complemento cuenta con 28 componentes con un total de 174 eventos y se integra directamente con 12 complementos populares. De todas las opciones de registro de auditoría, esta es la más completa.
Transmisión (gratis)
El plugin registra las acciones de los usuarios y del sistema de WordPress en los registros de Stream. Cada acción de los usuarios conectados se muestra en un flujo de actividad y se organiza para facilitar su filtrado por usuario, rol, contexto, acción o dirección IP. Los administradores pueden destacar entradas en el registro de Stream, como la actividad sospechosa de un usuario, para investigar qué sucede en tiempo real. Stream también permite configurar alertas por correo electrónico y webhooks para integraciones como Slack e IFTTT, para notificar a tu equipo y a ti cuando algo sale mal.
La transmisión es completamente gratuita y no tiene plan profesional.
Registro de actividades de Aryo (gratis)
Otro complemento de monitorización de actividad, también totalmente gratuito.
DecaLog (Gratis)
Si bien DecaLog no registra específicamente eventos de usuario, tiene la maravillosa función de registrar varios eventos en un sitio que no son registrados ni por Stream ni por Aryo, lo que le brinda diferentes perspectivas sobre los procesos en segundo plano, lo que hace que sea más fácil detectar malware en el acto.
Si tiene problemas para interpretar los resultados, le sugiero tomar una captura de pantalla de los registros y luego subirla a un bot de IA para que los interprete. Puede acceder a bots de IA de pago de forma gratuita a través de PoE .
Actualizar automáticamente el software del servidor
Software de servidor obsoleto
El software obsoleto, como versiones antiguas de PHP, MySQL, NGINX, Apache o Varnish, puede causar graves problemas de seguridad. Se publican parches para este software con regularidad, y es muy recomendable actualizarlo regularmente para mitigar incidentes de seguridad.
Programar trabajos cron del sistema (gratis)
Estas actualizaciones se pueden automatizar mediante trabajos cron.
Artículo sobre la velocidad de la colmena
Generadores de trabajos cron del sistema
Generadores de trabajos cron del sistema gratuitos
Cronhub (gratis)
Crontab Guru (Gratis)
Generador de crontab (gratis)
Monitoreo de cambios de archivos
Monitor de cambios en archivos del sitio web (gratis)
Reciba alertas por correo electrónico sobre los cambios de archivos en sus sitios de WordPress para aumentar la confiabilidad y la seguridad
Alta carga de CPU y presión excesiva de RAM
Incidentes de seguridad
Además de las infecciones de malware, los ataques de fuerza bruta, los DDoS y otros incidentes de seguridad, el alto uso de la CPU y la presión de la RAM pueden ser causados por otros factores.
Carga excesiva de la base de datos
Una gran cantidad de opciones cargadas automáticamente, una cantidad excesiva de revisiones, una cantidad excesiva de transitorios, tablas de bases de datos infladas, consultas lentas, falta de almacenamiento en caché de objetos, falta de índices en tablas específicas pueden provocar una alta carga de CPU y una presión excesiva de RAM.
Mitigaciones
Cantidad excesiva de trabajos cron de WordPress
Deshabilitar los cronjobs de WordPress y habilitar los cronjobs del servidor (gratis)
Artículo para principiantes de WP
Generadores de trabajos cron del sistema
Generadores de trabajos cron gratuitos del sistema
Cronhub (gratis)
Crontab Guru (Gratis)
Generador de crontab (gratis)
Escalado automático de servidores en la nube (pago)
Muchos proveedores de VPS en la nube y sin servidor cuentan con una función de escalado automático que actualiza o reduce automáticamente los recursos de su servidor según la carga. Este servicio se basa en el uso y no tiene un costo mensual fijo. El escalado automático es necesario en sitios con mucho tráfico.
Demasiadas pestañas de WP-Admin abiertas simultáneamente
Tener demasiadas pestañas del backend de WP Admin abiertas simultáneamente puede causar una carga excesiva de CPU y RAM, incluso con otras mitigaciones aplicadas. Modificar el intervalo de Heartbeat de WordPress puede mitigar parte del impacto en el rendimiento de varias pestañas de WP Admin en tu navegador.
Latido del corazón de WordPress
Artículo para principiantes de WP
https://www.wpbeginner.com/plugins/how-to-limit-heartbeat-api-in-wordpress
Explicación muy breve de la funcionalidad Heartbeat de WordPress.
Control dinámico de latidos del corazón de WordPress en la interfaz (gratis)
El plugin ofrece un método eficiente para controlar dinámicamente el ritmo del frontend, determinando automáticamente la configuración óptima para tu sitio web. Al analizar el uso del usuario, los recursos del sitio WordPress y el entorno del servidor, optimiza el rendimiento de tu WordPress para alcanzar su máximo potencial.
Una vez activado, mejora el rendimiento de inmediato sin necesidad de intervención del usuario. Ajusta inteligentemente el intervalo de latidos en tiempo real, adaptándose a las necesidades cambiantes de su sitio web. Este control dinámico garantiza un sistema de latidos optimizado y eficiente, lo que se traduce en un mejor rendimiento general y una mayor capacidad de respuesta.
Mejoras de administración y del sitio (gratis)
Las mejoras de administración y del sitio también permiten controlar la frecuencia de latidos. Es menos flexible que el control dinámico de latidos del frontend.
Ajustar la configuración de MySQL (gratis)
Sintonización automática
Sintonizador de MySQL (gratuito)
https://github.com/major/MySQLTuner-perl
MySQLTuner es un script escrito en Perl que permite revisar rápidamente una instalación de MySQL y realizar ajustes para mejorar el rendimiento y la estabilidad. Las variables de configuración actuales y los datos de estado se recuperan y presentan de forma breve, junto con algunas sugerencias básicas de rendimiento.
MySQLTuner admite ~300 indicadores para MySQL/MariaDB/Percona Server en esta la
Releem (Pagado)
Releem ajustará automáticamente su configuración de MySQL en un VPS y ajustará la configuración en función de la carga de MySQL actual y promedio en el servidor.
Reducir las opciones de carga automática
Sweeppress (Gratis)
Modificar la configuración de carga automática o eliminar las opciones de carga automática
Optimizador de opciones AAA (gratis)
Otro complemento de optimización de opciones de carga automática
Almacenamiento en caché de objetos
Caché de expediente (gratuito)
La caché de Dockets se puede usar cuando no se puede instalar Redis (por ejemplo, algunos planes de hosting compartido no la tienen). Es una caché de objetos, al igual que Redis, pero funciona a nivel de WordPress y no a nivel de servidor. En muchos casos, puede ofrecer un mejor rendimiento que Redis.
Redis (Gratis)
Guía de optimización del rendimiento de Dragonfly Redis
https://www.dragonflydb.io/guides/redis-memory-and-rendimiento-optimización
Artículo extenso sobre cómo optimizar el rendimiento de Redis.
Información general de Redis para WordPress
Redis también es un servicio a nivel de servidor, por lo que necesitarás un plugin de WordPress para usarlo como conector. Para que el plugin funcione, Redis debe estar instalado en tu VPS o por tu proveedor de hosting.
Caché de objetos de Redis (gratuito)
Caché de objetos Redis desarrollado por Till Krüss.