Por qué su sitio de WordPress es tan lento y una guía práctica para acelerar las cosas

Quería comenzar esta publicación haciéndole saber que este NO es solo otro artículo genérico de “Cómo acelerar WordPress”.

No voy a regurgitar nada que ya se pueda encontrar en la web. No te voy a decir que debes instalar un complemento de almacenamiento en caché, habilitar la compresión, minimizar tu css / js, etc.

Después de todo, ya debería saber cómo hacer estas cosas. Y si no lo hace, puede encontrar esta información genérica en cientos de otros blogs.

En cambio, este artículo contiene todo lo personalizado / semi-personalizado que he implementado en el último mes para acelerar mi propio blog de WordPress y, básicamente, evitar que los accesos no autorizados dejen de funcionar mi servidor.

Y la razón por la que es "poco conocido" es porque las técnicas que voy a describir serán muy específicas para su propio blog, dependiendo de los patrones de tráfico que esté viendo.

Nota: Si tienes un blog lento y realmente no quieres lidiar con ninguno de los aspectos técnicos de acelerar un sitio web, probablemente debas registrarte en un servicio como WP Engine .

Estos chicos se especializan en alojamiento de WordPress y se asegurarán de que su blog se ejecute lo más rápido posible. Pero, naturalmente, esto tiene un precio. Deberías echarles un vistazo si esta publicación pasa por encima de tu cabeza :)

De todos modos, antes de que pueda explicarte cómo y por qué hice lo que hice con mi blog, debes comprender algunos conceptos fundamentales sobre WordPress y el almacenamiento en caché que describiré a continuación.

Algunos datos interesantes de WordPress

Digamos que ya ha seguido todas las pautas sobre cómo acelerar WordPress. Tu blog se siente animado. Webpagetest.org te dice que tu blog es increíblemente rápido. Todo está bien, ¿verdad? No necesariamente .

Solía ​​sentir exactamente lo mismo con mi blog. Después de todo, sigo la mayoría de los protocolos de aceleración estándar. Ejecuto muy pocos complementos y mi blog se siente bastante rápido con un uso normal desde la perspectiva de un lector humano (las redes publicitarias son las que ralentizan mi blog, por lo que cargo los anuncios al final).

Pero luego comencé a analizar los gráficos de uso de mi CPU y, a menudo, noté períodos de alta carga del servidor a pesar de los niveles de tráfico bajos a moderados. Ocasionalmente, mi servidor incluso se volvía inutilizable o no respondía durante períodos prolongados.

Tenga en cuenta que la única razón por la que comencé a prestar atención a estas estadísticas fue porque hace un tiempo estaba ejecutando mi tienda en línea en el mismo servidor que mi blog. Y periódicamente tenía clientes que se quejaban de que la tienda era extremadamente lenta. Cuando finalmente investigué un poco, descubrí que mi blog de WordPress optimizado y completamente almacenado en caché estaba poniendo de rodillas mi servidor.

¿Moraleja de la historia? El hecho de que una prueba de velocidad te diga que tu blog es rápido no significa necesariamente que todo esté bien.

Aquí hay algunos datos divertidos sobre WordPress y los complementos de almacenamiento en caché como WP Super Cache y W3 Total Cache que debe conocer.

• Las respuestas 404 de WordPress son lentas . Cada vez que su blog recibe acceso a una página que no existe, su pobre servidor tiene que cargar WordPress, ejecutar un montón de código php, hacer un montón de consultas MySQL y luego escupir su página 404 personalizada de WordPress. Esta es una tarea que requiere muchos recursos y el almacenamiento en caché no ayudará.
• Su complemento de almacenamiento en caché no funciona muy bien cuando hay parámetros GET en la URL. Por ejemplo, solía notar que mi blog se ralentizaba cada vez que enviaba una explosión a mi lista de correo electrónico. En teoría, con el almacenamiento en caché de archivos estáticos, mi servidor debería ser casi invencible.

  Pero debido a que Aweber inserta parámetros de seguimiento en la URL, ninguno de mis archivos está súper guardado en caché. Como resultado, WordPress tiene que generar un nuevo archivo de caché (aunque ya existe), comprimirlo y enviarlo cada vez. La peor parte es que estos archivos en caché solo se usan una vez, lo que lo convierte en un desperdicio de recursos del servidor.

• Los accesos no autorizados son lentos. Debido a que los accesos fraudulentos requieren que WordPress se cargue de forma predeterminada, un robot o rastreador incorrecto que decida enviar spam a su sitio con solicitudes incorrectas puede acabar con su blog con bastante facilidad.
• Su complemento de almacenamiento en caché puede tener un error o una incompatibilidad con la forma en que ha configurado su blog . Por ejemplo, durante 3 años pensé que WP Super Cache estaba haciendo lo correcto hasta que comencé a ver mis registros y noté un error en el código. Debido a la forma en que configuré las cosas, tuve un problema en el que WP Super Cache estaba limpiando mi caché con demasiada frecuencia.

El punto clave que estoy tratando de hacer con las viñetas anteriores es que cada vez que ocurre un acceso no estándar en su blog, se gastan muchos recursos del servidor sin importar cómo tenga la configuración de su blog de WordPress. Y son estos tipos de accesos los que pondrán de rodillas a su servidor, no al tráfico regular.

Detectar accesos no autorizados

La primera clave para optimizar su blog de WordPress es comprender los patrones de tráfico que recibe su blog. Estoy dispuesto a apostar a que el 99% de los usuarios de WordPress no hacen esto. En cambio, siguen e instalan ciegamente varios complementos y asumen que todo funciona correctamente. No te sientas mal, yo estaba de la misma manera.

Así que el primer paso es averiguar qué diablos está pasando. Hay muchas formas de hacer esto, pero la forma más sencilla es utilizar el modo de depuración que proporciona el complemento WP SuperCache. ¿Qué hace este modo? Básicamente, cada vez que WordPress maneja directamente un acceso (uso intensivo de recursos), aparecerá en el registro de WP Super Cache. Así es como habilita este modo.

Debajo de la pestaña de depuración de su WP Super Cache Plugin, simplemente haga clic en la casilla de verificación "Depuración habilitada" y ¡listo!

Una vez que el registro está habilitado, puede hacer clic en el enlace "archivo de registro" que lo dirigirá a un archivo que detalla su tráfico de WordPress. Se verá similar al texto a continuación.

15:03:46 /?utm_source=fwisp.com supercache dir:
15:03:46 /?utm_source=fwisp.com No wp-cache file exists. Must generate a new one.
15:03:46 /?utm_source=fwisp.com In WP Cache Phase 2
15:03:46 /?utm_source=fwisp.com Setting up WordPress actions
15:03:46 /?utm_source=fwisp.com Supercache caching disabled. Only using wp-cache. Non empty GET request.
15:03:46 /?utm_source=fwisp.com USER AGENT (Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)) rejected. Not Caching

Lo importante a tener en cuenta es que cada vez que ve algo en este registro, es algo malo porque significa que WordPress tiene que funcionar. Y debido a que WordPress es un acaparador de recursos, desea que haga el menor trabajo posible.

Qué buscar en los registros

Los registros de WP Super Cache son geniales porque te dicen todo lo que está sucediendo. Pero la gran cantidad de información puede ser abrumadora a menos que sepa qué buscar. Esto es a lo que debe prestar atención en estos registros.

• Errores 404 : básicamente, estos son accesos a páginas que no existen en tu blog. Cada acceso 404 manejado por WordPress consume una gran cantidad de recursos del servidor, por lo que debe cortarlos de raíz si es posible
• Accesos únicos : estas son solicitudes que hacen que su servidor almacene en caché y comprima páginas que solo se usarán una vez (más sobre esto más adelante)
• Ráfagas extrañas de tráfico : estos suelen ser robots que golpean tu blog de una vez
• Comportamiento extraño de almacenamiento en caché : ¿sus cachés se vacían cuando deberían? ¿Todo se almacena en caché correctamente en todas las circunstancias?

Después de mantener un registro del tráfico de mi blog durante un período de 2 semanas, descubrí muchas ineficiencias que describiré a continuación.

Los bots estaban martillando mis archivos

Lo primero que hice fue mirar los registros de mi servidor en busca de períodos de alta carga de CPU. Luego, analicé mis registros de súper caché durante estos mismos períodos exactos para ver si había algún negocio divertido. ¡Resulta que una vez cada dos días, un grupo de bots venía y martillaba todas las páginas de archivo de mi blog al mismo tiempo!

Debido a que estas páginas de archivo no se almacenan en caché de forma predeterminada, un montón de accesos simultáneos fue suficiente para aumentar la carga de mi servidor y hace que las cosas sean extremadamente lentas. Y ocasionalmente, incluso causó que mi servidor fallara.

Así que eché un vistazo más de cerca a mi salida HTML y noté que tenía un montón de enlaces de archivo como parte de mi encabezado de WordPress. Por lo tanto, los bots y otros rastreadores web vendrían e intentarían explorar los archivos.

Después de mucho buscar en Google, descubrí que algunos otros webmasters tenían problemas similares.

Cuando vemos problemas de carga con su sitio muchas veces, hay una gran cantidad de accesos para las IP del servidor proxy y la teoría es que estos proxies están almacenando en caché su sitio y golpeando todos esos enlaces de archivo. Muchas de las direcciones IP que vemos cuando su sitio está causando problemas de carga son direcciones IP de proxy corporativas, educativas y gubernamentales / militares que parecen buscar previamente el contenido cuando alguien accede a un sitio.

Solución: compruebe si tiene la declaración php "wp_get_archives" en el código de encabezado de su blog y elimínela. Después de eliminar este pequeño fragmento, todos mis accesos a archivos desaparecieron.

Los bots estaban accediendo a archivos inexistentes

La segunda cosa importante que noté fue que había un montón de bots que estaban accediendo a archivos en mi servidor que no existían. El problema es que cada vez que ocurre un acceso a un archivo, su servidor tiene que cargar WordPress, ejecutar un montón de código PHP y luego emitir una página 404.

La solución a este problema es editar el archivo .htaccess (Google esto si no sabe qué es) y agregar las siguientes líneas.

RewriteCond% {REQUEST_FILENAME}! -F
RewriteCond% {REQUEST_FILENAME}! -D
RewriteCond% {REQUEST_URI}! (Robots \ .txt | mapa del sitio \ .xml (\. Gz)?)
RewriteCond% {REQUEST_FILENAME} \. (Css | js | html | htm | rtf | rtx | svg
| svgz | txt | xsd | xsl | xml | asf | asx | cera | wmv | wmx | avi | bmp | clase | divx | doc
| docx | exe | gif | gz | gzip | ico | jpg | jpeg | jpe | mdb | mid | midi | mov | qt | mp3 |
m4a | mp4 | m4v | mpeg | mpg | mpe | mpp | odb | odc | odf | odg | odp | ods | odt | ogg | pdf
| png | olla | pps | ppt | pptx | ra | ram | rar | swf | tar | tif | tiff | wav | wma | wri |
xla | xls | xlsx | xlt | xlw | zip) $ [NC]
RewriteRule. * - [L]

Una vez que estas líneas se insertan en su archivo .htaccess, su servidor web primero verificará si existe un archivo. De lo contrario, emitirá una respuesta 404 SIN cargar WordPress.

Los bots estaban accediendo a URL que no existían

Lo desafortunado de la forma en que está escrito WordPress es que si hay un acceso a un artículo que no existe en su base de datos, su servidor tendrá que cargar WordPress, ejecutar un montón de código PHP y realizar un montón de búsquedas en MySQL antes de emitir un Respuesta 404.

Si observa sus registros con atención, probablemente notará ciertos patrones de acceso que puede excluir antes de que lleguen a WordPress.

Por ejemplo, noté que un montón de bots estaban accediendo a mi sitio con la URL www.mywifequitherjob.com/some-article/www.facebook.com/like.php/… . Y cada vez, mi servidor cargaba WordPress y emitía una respuesta 404.

Entonces, en lugar de que WordPress maneje estas solicitudes, agregué las siguientes líneas a mi archivo .htaccess

RewriteCond% {REQUEST_FILENAME}! -F
RewriteCond% {REQUEST_FILENAME}! -D
RewriteCond% {REQUEST_URI} www \ .facebook \ .com / plugins [NC]
RewriteRule. * 404.html [L, R = 404]

En las líneas anteriores, hago que mi servidor web busque “www.facebook.com/plugins” en la URL y emita inmediatamente una respuesta 404 sin cargar WordPress. Mientras examina sus registros, encontrará muchos accesos no autorizados como el que describí anteriormente. Escriba una regla .htaccess para cada uno y estos accesos ya no cargarán su servidor.

Los bots estaban martillando mis enlaces de comentarios

¿Recuerda cuando le dije que las URL con parámetros GET se manejan de manera diferente por su complemento de almacenamiento en caché? Descubrí que había un montón de bots machacando mis artículos con el conjunto de parámetros "responder al comentario".

Cuando esto sucede (dependiendo de la configuración de almacenamiento en caché), wordpress se carga y se sirve un archivo en caché / zip, aunque probablemente nunca se volverá a acceder a él. Esto es un desperdicio de recursos.

Ejemplo tomado de mi registro
12:01:11 /how-to-get-more-facebook-fans-with-a-facebook-reveal-tab-or-fan-gate/?replytocom=5972 No wp-cache file exists. Must generate a new one.
12:01:11 /how-to-get-more-facebook-fans-with-a-facebook-reveal-tab-or-fan-gate/?replytocom=5972 Gzipping buffer.

La solución es redirigir todos los bots y rastreadores con estos parámetros GET a la página principal del artículo. Aquí está el código que agregué a mi archivo .htaccess.

RewriteCond% {QUERY_STRING} replytocom
RewriteCond% {HTTP_USER_AGENT} ^ (. *) (Bot | rastreo | araña | slurp) [NC]
RewriteRule. * Https: //mywifequitherjob.com% {REQUEST_URI}? [L]

Este código busca el parámetro GET “replytocom” y luego elimina este parámetro de la URL final antes de presentar el acceso a WordPress.

Los rastreadores accedían a las publicaciones sin una barra al final

No estoy seguro de por qué es así, pero noté un grupo de rastreadores web que parecían estar legítimamente tratando de acceder a los artículos de mi blog sin una barra inclinada en la URL.

Como puede que sepa o no, una URL escrita como http://yourblog.com/article/ es diferente a una URL escrita como http://yourblog.com/article .

Como resultado, cuando se encuentra una URL sin una barra al final, WordPress tiene que intervenir, ejecutar un montón de código PHP y luego emitir un redireccionamiento 301 al artículo con la barra al final. Para sacar WordPress de la imagen, simplemente puede insertar la siguiente regla en su archivo .htaccess.

# Agregar barra al final
RewriteCond% {REQUEST_FILENAME}! -F
RewriteCond% {REQUEST_URI}! (. *) / $
RewriteCond% {QUERY_STRING}!. * =. *
RewriteRule ^ (. *) $ $ 1 / [L, R = 301]

Al agregar una barra diagonal, está emitiendo el redireccionamiento 301 a la URL correcta antes de que llegue a WordPress, lo que ahorrará recursos de CPU.

Encontré un error en WP Super Cache

A diferencia de la mayoría de la gente, no tengo mi blog de WordPress instalado en la raíz de mi directorio public_html. Además, la página principal de mi blog tampoco es mi página de "publicaciones". Cuando tienes tu blog configurado de la misma manera que yo, hay un error en WP Super Cache donde todos tus archivos de caché podrían borrarse prematuramente incluso si precargas tu caché.

No estoy seguro de si el autor del complemento está al tanto de este problema, pero básicamente descubrí que cada vez que se emitía un comentario de spam en mi blog, todo mi caché se vacía por error. Como recibo spam de comentarios y trackback todo el tiempo, mi caché se vaciaba constantemente, lo que hacía que el almacenamiento en caché fuera mucho menos eficiente.

Así que pasé un fin de semana depurando este problema y finalmente desarrollé una solución. Si alguno de ustedes tiene los mismos problemas, avíseme y le mostraré mi solución. La moraleja de la historia aquí es nunca asumir que su complemento de almacenamiento en caché simplemente funciona. ¡Tienes que mirar los registros!

Deshabilitar complementos intensivos de CPU

Incluso si ha seguido todos mis pasos anteriores, es imposible filtrar todos los accesos no autorizados antes de que lleguen a su blog de WordPress.

Por lo tanto, siempre recibirá visitas a su sitio que no se manejarán de manera eficiente. No hay forma de evitarlo.

Pero lo importante a tener en cuenta es que lo más probable es que no tenga un problema de ancho de banda, tendrá un problema de CPU.

Como resultado (y esto puede ser contrario a la intuición), en realidad no desea hacer nada que requiera un uso intensivo de la CPU, como "minificar" o "comprimir" sus páginas sobre la marcha. La minificación y la compresión ayudan con el ancho de banda a expensas del uso de la CPU.

Lo último que desea hacer es minificar y almacenar en caché los accesos no autorizados. De hecho, probablemente tampoco debería considerar no minificar ni comprimir URL con parámetros GET.

Lo más importante es que no debería ejecutar ningún complemento de CPU intensivo en su sitio. WP-Engine tiene una gran lista de complementos de CPU intensivos que probablemente deberías intentar evitar.

Mientras examinaba mi lista de complementos, noté que estaba usando un complemento de "publicaciones similares". Y cuando eché un vistazo al código fuente, me horroricé al descubrir que el complemento estaba haciendo comparaciones de texto completo para encontrar artículos similares, lo cual es un drenaje de CPU importante y no escalable.

Tan pronto como encuentre un reemplazo adecuado, este complemento definitivamente se irá a la basura.

Moraleja de la historia

El hecho de que una prueba de velocidad en línea te diga que tu blog es rápido no significa mucho en el gran esquema de las cosas.

No me malinterpretes. La velocidad de carga de la página es importante para los motores de búsqueda y para sus clientes habituales, pero también debe tener en cuenta los accesos fraudulentos que pueden eludir su caché y hacer que su servidor caiga de rodillas.

Por lo tanto, no instale el almacenamiento en caché y otros complementos de aceleración a ciegas. Tómese su tiempo para analizar su tráfico y escribir tantas reglas .htaccess como sea posible para minimizar el trabajo que tiene que realizar WordPress. ¡Buena suerte!