Pasos para optimizar WordPress con respecto a la carga del servidor?

Además de instalar W3 Total Cache u otro plugin de almacenamiento en caché, ¿qué pasos puedo seguir para asegurarme de que mi tema y sitio funcionen lo más rápido posible?

Puedes instalar WordPress en Nginx. Hay varios recursos para ayudar:

• Complemento de compatibilidad nginx

• Cómo: Instalar WordPress en Nginx -

• Discusión de Slicehost

• Cómo acelerar WordPress con Nginx y WP Super Cache

• WordPress en nginx + lighttpd + FastCGI + php

• Nginx como caché de proxy front-end para WordPress

Parte de la información de rendimiento de ese último enlace (que parece ser una configuración un poco diferente a las demás):

Así que decidí poner un proxy delante de WordPress a la caché estática tanto como sea posible. TODO el tráfico no autenticado se sirve directamente desde la caché de archivos nginx, tomando algunas solicitudes (como la generación de fuentes RSS) de 6 páginas / segundo a más de 7000 páginas / segundo. Oof Nginx también maneja el registro y el gzipping, dejando que los apaches backend más pesados ​​hagan lo que mejor saben hacer: servir páginas dinámicas de wordpress solo cuando sea necesario.

...

En nginx, es tan eficiente que da miedo. Nunca lo he visto usar más de 10 a 15 meg de RAM y una pizca de CPU, incluso bajo nuestra mayor carga. Nuestros gráficos de ganglios no mienten: redujimos a la mitad nuestros requisitos de memoria, duplicamos el rendimiento de nuestra red saliente y nivelamos completamente nuestra carga. Básicamente no hemos tenido problemas desde que configuramos esto.

Establezca los vencimientos del lado del cliente para cosas como css, imágenes, JavaScript, etc., que no es necesario volver a descargar para cada vista de página. Esto, por mucho, marcó la mayor diferencia en los tiempos de carga de mi sitio. La descarga más rápida es la descarga que nunca sucedió ...

# BEGIN Expire headers
<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresDefault "access plus 7200 seconds"
  ExpiresByType image/x-icon "access plus 2592000 seconds"
  ExpiresByType image/jpeg "access plus 2592000 seconds"
  ExpiresByType image/png "access plus 2592000 seconds"
  ExpiresByType image/gif "access plus 2592000 seconds"
  ExpiresByType application/x-shockwave-flash "access plus 2592000 seconds"
  ExpiresByType text/css "access plus 2592000 seconds"
  ExpiresByType text/javascript "access plus 2592000 seconds"
  ExpiresByType application/x-javascript "access plus 2592000 seconds"
  ExpiresByType text/html "access plus 7200 seconds"
  ExpiresByType application/xhtml+xml "access plus 7200 seconds"
</IfModule>
# END Expire headers

# BEGIN Cache-Control Headers
<IfModule mod_headers.c>
  <FilesMatch "\\.(ico|jpe?g|png|gif|swf|gz)$">
    Header set Cache-Control "max-age=2592000, public"
  </FilesMatch>
  <FilesMatch "\\.(css)$">
    Header set Cache-Control "max-age=2592000, public"
  </FilesMatch>
  <FilesMatch "\\.(js)$">
    Header set Cache-Control "max-age=2592000, private"
  </FilesMatch>
<filesMatch "\\.(html|htm)$">
Header set Cache-Control "max-age=7200, public"
</filesMatch>
# Disable caching for scripts and other dynamic files
<FilesMatch "\.(pl|php|cgi|spl|scgi|fcgi)$">
Header unset Cache-Control
</FilesMatch>
</IfModule>
# END Cache-Control Headers

Puede precomprimir todo lo que razonablemente pueda (7-zip es una buena herramienta para esto) y cargarlo en el mismo lugar que el archivo que acaba de comprimir. Cambie .htaccess para servir los archivos precomprimidos, como se muestra a continuación. La advertencia aquí es que debes recordar volver a comprimirlos si / cuando actualizas cosas. Esto corta la sobrecarga de la CPU, además de analizar .htaccess.

RewriteEngine on
#Check to see if browser can accept gzip files. If so and we have it - serve it!
ReWriteCond %{HTTP:accept-encoding} gzip
RewriteCond %{HTTP_USER_AGENT} !Safari
#make sure there's no trailing .gz on the url
ReWriteCond %{REQUEST_FILENAME} !^.+\.gz$
#check to see if a .gz version of the file exists.
RewriteCond %{REQUEST_FILENAME}.gz -f
#All conditions met so add .gz to URL filename (invisibly)
RewriteRule ^(.+) $1.gz [QSA,L]

Esta es solo una respuesta cruda. Hay muchas variaciones sobre este tema. Publiqué un blog sobre esto y agregué bastantes referencias a artículos más detallados en http://icanhazdot.net/2010/03/23/some-wordpress-stuff/ . Lea eso y, lo que es más importante, las referencias que señalo: son buenos recursos.

Tenga en cuenta que si juega con frecuencia, los usuarios deberán actualizar su caché.

Un complemento que encontré muy útil también es wp-minify . Lo que hay que ver con este es que debe excluir elementos específicos de la página (formulario de contacto, control deslizante de la página principal, etc.) para no volver a descargar todo el conjunto de CSS, JS, etc. para cada página. Es una buena manera de minificar, combinar y comprimir su CSS de línea de base, JS, etc. Reduce mucho las solicitudes http. Wp-minify funciona bien con supercaché y también con encabezados de caducidad que detallé anteriormente.

Use Yslow en Firebug (Firefox) o similar para monitorear sus solicitudes http y lo que está y no está comprimido. Echa un vistazo a los encabezados de caducidad allí también. Pronto verá lo que puede mejorar.

Minimice la cantidad de complementos que ejecuta solo para lo que realmente necesita. Especialmente tenga en cuenta los complementos que agregan código JavaScript y CSS en cada carga de la página, incluso cuando ese código no se utiliza en la página.

Si está creando su propio tema desde cero, divida su CSS para que las características que solo se necesitan para plantillas de página o tipos de vista específicos (publicación única, archivos, categoría, etc.) solo se carguen cuando sea necesario.

Configure W3TC para usar un CDN (como Amazon CloudFront o cualquiera de los otros compatibles con W3TC).

Vea si las opciones de Minify funcionan para usted (algunos complementos generan js / css que no se minificarán bien, así que asegúrese de probar su sitio después de activar la función minify).

Si tiene el control total de su servidor MySQL, asegúrese de tener el query_cache activado. Use un script de ajuste MySQL para encontrar otras formas de optimizar la configuración de su base de datos.

Si usar un CDN es problemático por alguna razón, configure mod_expires en su configuración de apache. Establezca tiempos de vencimiento tan largos como sea razonable para tipos estáticos como imágenes, CSS, JavaScript, video, audio, etc.

Ejecute memcached y use un caché de objetos para reducir la cantidad de consultas a la base de datos. Esto almacena en caché los datos de la base de datos, en lugar de las páginas. No estoy seguro si w3-total-cache ya hace esto.

Asegúrese de ejecutar un caché de código de operación como APC . (Hay varios más disponibles).

Además de utilizar un complemento de almacenamiento en caché de disco como wp-cache, coloque su blog en un volumen de host que tenga establecida la propiedad "noatime". De lo contrario, ingrese SSH en su host (si su servidor web lo proporciona) y ejecute habitualmente este comando en sus archivos cada pocos días:

chattr -R +A ~/*

El ~ / * significa "mis archivos en mi directorio de inicio". Puede cambiar ese camino como mejor le parezca. También puede configurar esto en un trabajo cron en cpanel si su servidor web lo proporciona.

Para obtener más información sobre la propiedad atime, consulte esto . Acelera enormemente el rendimiento de lectura de disco de Linux.

A veces su sitio está siendo golpeado por arañas. Puede usar una herramienta como SpyderSpanker o Chennai Central para filtrar las arañas que no ayudan a aumentar el rango de la página en su sitio y simplemente ralentizarlo, y luego estrangular las buenas arañas (como Google, Bing, etc.) enviándolas al azar Mensajes HTTP 304 no modificados.

Otra cosa que veo son complementos mal escritos. Si aprende a hacer complementos, comenzará a ver cómo algunos complementos están codificados de manera ineficiente, o incluso encontrará bombas de tiempo, como una tabla de base de datos que se llena y llena y nunca se limpia, almacenando cosas como datos de conexión entrantes.

Más allá de todas las otras soluciones aquí, también puede crear una granja de servidores web de WordPress de su blog alojándola en varias PC de nodo web que se conectan de nuevo a una sola base de datos y un único volumen de disco para los archivos (como un volumen montado sobre NFS ) Echa un vistazo a Ultra Monkey para saber cómo hacer que todo funcione.

Algunas respuestas en la parte superior de mi cabeza:

1) Minimice la cantidad de solicitudes HTTP que el navegador debe hacer a su host concatenando JavaScript y CSS cuando sea posible / práctico.

2) Descargue la mayor cantidad posible de imágenes / medios a CDN de terceros, especialmente si está utilizando un alojamiento compartido.

3) Intenta reducir la cantidad de publicaciones que estás mostrando en la página principal para reducir el tiempo total de renderizado.

3a) Intente usar un tema que presente algunas publicaciones destacadas en su totalidad en la página principal y todas las demás publicaciones antiguas como extractos.

El almacenamiento en caché del menú de WordPress también le brinda un aumento de rendimiento. Especialmente si tiene muchas páginas o una estructura de menú gigante, esto debe considerarse.

Hazlo en 2 sencillos pasos. Al principio, cree una función que obtenga o cree el menú, en lugar de llamar wp_nav_menudirectamente.

function get_cached_menu( $menuargs ) {

    if ( !isset( $menuargs['menu'] ) ) {

        $theme_locations = get_nav_menu_locations();
        $nav_menu_selected_id = $theme_locations[$menuargs['theme_location']];
        $termslug = get_term_by( 'id', $nav_menu_selected_id, 'nav_menu' );
        $transient = 'menu_' . $termslug->slug . '_transient';

    } else {

        $transient = 'menu_' . $menuargs['menu'] . '_transient';

    }


    if ( !get_transient( $transient ) ) { // check if the menu is already cached

        $menuargs['echo'] = '0'; // set the output to return
        $this_menu = wp_nav_menu( $menuargs ); // build the menu with the given $menuargs
        echo $this_menu; // output the menu for this run
        set_transient( $transient, $this_menu ); // set the transient, where the build HTML is saved

    } else {

        echo get_transient( $transient ); // just output the cached version

    }

}

En su tema, reemplace la wp_nav_menus con get_cached_menu. Ahora, cada vez que se llama al menú, tiene una consulta de base de datos en lugar del Menubuilding completo.

Los menús no cambian con frecuencia, pero también debe conectarse a la wp_update_nav_menuacción para eliminar los antiguos transitorios.

Hazlo asi:

add_action('wp_update_nav_menu', 'my_delete_menu_transients');

function my_delete_menu_transients($nav_menu_selected_id) {

    $termslug = get_term_by( 'id', $nav_menu_selected_id, 'nav_menu' );

    $transient = 'menu_' . $termslug->slug . '_transient';

    delete_transient( $transient ); 

}

El menú se generará la próxima vez que se llame a la página, y use la versión en caché hasta que alguien actualice el menú nuevamente.

Versión actualizada

Gracias @helgatheviking por señalar un error entre las babosas y las identificaciones. Actualicé las funciones para que funcione tanto con theme_positiony menu(para una llamada directa del menú).

Los menús siempre se guardan con el nombre del menú, no la posición en el tema.

Use una clase de base de datos que esté recortada para la optimización. Hicimos buenas experiencias con código propio para reducir el uso de memoria y la velocidad de acceso a la base de datos. Además de eso, puede optimizar la estructura de la base de datos en sí mediante algunos pequeños cambios que también hacen mucho.

Parte del código de clase de la base de datos se puede encontrar en el seguimiento de WordPress, no lo hizo en el núcleo ( Ticket # 11799 y relacionado ).

Para un sitio con mucho tráfico, debe ajustar todos los búferes de MySQL para el contenido que está en su lugar ahora. Independientemente de la versión de WordPress, la capa MySQL puede calcular su configuración .

De hecho, si tiene datos de InnoDB sin habilitar innodb_file_per_table, debe limpiar InnoDB segmentando cada tabla en su propio espacio de tabla físico . Es posible hacer un ajuste decente de MySQL incluso si tiene un hardware limitado . Hay muchos escenarios para hacer tales optimizaciones de InnoDB .

En mi humilde opinión, no puede planificar una buena configuración para my.cnf sin saber la cantidad de datos para configurar. Tendría que cargar periódicamente un conjunto de datos actual de la producción en un entorno intermedio, realizar optimizaciones y obtener los números para configurar en el my.cnf del servidor de producción.

podría habilitar la compresión de salida global . esto comprimirá todo lo que salga automáticamente si el navegador lo admite. Esto reduce drásticamente el tamaño de los archivos transferidos, pero aumenta la carga de su CPU.

Recientemente hablé sobre este tema en WordCamp Houston . Todas las recomendaciones anteriores son geniales y lo importante es asegurarse de que todo el front-end esté completamente optimizado para que pueda comenzar a trabajar en los problemas de caché y rendimiento del servidor.

El renderizado progresivo hará que sus páginas se sientan más rápido porque el usuario verá el contenido de la página antes de que esté completamente cargada. Para hacer esto, asegúrese de que cualquier bloqueo js esté en la parte inferior de la página y css esté en la parte superior.

Además, si usa muchos botones de redes sociales, puede personalizar las secuencias de comandos para que se carguen en un iframe después de que la página esté completamente cargada. Escribí un tutorial sobre cómo hacerlo con el botón TweetMeMe re tweet (ahora obsoleto desde que Twitter lanzó su propio botón retweet), pero aún se puede aplicar a otros botones de compartir.

Para el rendimiento del servidor, busque en Nginx como un proxy front-end para contenido estático con Apache manejando el pesado levantamiento de PHP y MySQL.

Como nadie lo mencionó todavía, uno de los pasos más importantes para mejorar el rendimiento del servidor junto con cualquier configuración de LAMP sería cambiar a hilo de trabajador de apache y mod_fcgid.

Esto liberó 500 MB de memoria en mi servidor privado virtual.

Guía para verificar la ralentización del complemento

Hay un complemento maravillosamente simple llamado Tiempo de carga de la página , que agrega un temporizador al pie de página. En realidad son solo cuatro líneas de código:

<?php
function ur_pageload_footer() {
    printf(__('Page in %s seconds', 'pageload'), timer_stop());
}
add_action('wp_footer', 'ur_pageload_footer')

Entonces:

1. Crea una hoja de cálculo
2. Enumere todos sus complementos activos y colóquelos allí
3. Actualice la página tres veces observando el tiempo de carga de la página cada turno
4. Revisa tus complementos uno por uno desactivándolos
5. Repita el paso 3
6. Tenga en cuenta el orden en que desactivó los complementos

Su hoja de cálculo debería verse algo así

+-------+-------+-------+-------+--------+
| Run 1 | Run 2 | Run 3 | Order | Plugin |

Entonces, si después de desactivar un complemento, el tiempo de respuesta de la página aumenta significativamente, entonces puede ver si puede evitar ese complemento.

Encontré dos complementos que causaron una ralentización 'significativa' de mqtranslate y (el bastante antiguo pero bueno) complemento de navegación de varios niveles .

Quédese con el complemento W3 Total Cache para la funcionalidad de almacenamiento en caché en WordPress. Habilite el almacenamiento en caché de la página y de la base de datos desde la página de configuración del complemento. Asegúrese de elegir 'Caché PHP alternativa (APC / APCu)' como mecanismo de almacenamiento en caché. NO habilite ninguna minificación en W3 Total Cache ya que hay muchas posibilidades de que rompa la apariencia y / o funcionalidad de su sitio. Se lo dejaremos a Cloudflare.

Una vez que haya terminado de configurar el resto de las funcionalidades del complemento, configure Cloudflare para su sitio web. Asegúrese de habilitar Cloudflare en la configuración de W3 Total Cache también en 'Extensiones'.

Cloudflare es una red de entrega de contenido que almacena en caché todo el contenido estático (archivos de imagen, CSS, JS, documentos, etc.) de su sitio y lo sirve a sus visitantes desde sus servidores globales. Esto puede ayudar a acelerar los tiempos de carga de la página y reducir la carga en su servidor. Para obtener una lista de los tipos de archivo que Cloudlfare almacena en caché, consulte esta lista . Además, Cloudflare tiene un plan gratuito.

En Cloudflare, establezca el nivel de almacenamiento en caché en estándar y la caducidad de la memoria caché del navegador en algo por lo menos mayor de 20 horas. Habilite Always Online ™ para que incluso si su servidor se cae, Cloudflare servirá las páginas estáticas de su sitio web desde su caché. También habilite su función de minificación automática (¿recuerda por qué le pedí que no habilite la minificación en W3 Total Cache? ¡Porque Cloudflare lo hace mejor!) Luego configure Rocket Loader ™ en automático.

Aquí hay un extracto de lo que hace Rocket Loader:

• Disminuir la cantidad de solicitudes de red agrupando archivos JavaScript, incluso recursos de terceros, para evitar ralentizar el procesamiento de la página.

• Carga de secuencias de comandos de forma asíncrona, incluidas las secuencias de comandos de terceros, para
  que no bloqueen la carga del contenido de su página de
  inmediato.

• Almacenamiento en caché de scripts localmente (usando LocalStorage, disponible en la mayoría de los
  navegadores y teléfonos inteligentes) para que no se vuelvan a buscar a menos
  que sea necesario.

Más información se puede encontrar aquí .

Si es posible, cambie al marco Genesis para WordPress porque están limpios sin ninguna hinchazón. Genesis fue construido teniendo en cuenta la velocidad y el SEO. Yo mismo lo he probado y mis puntuaciones de PageSpeed ​​fueron buenas. Además, si está utilizando Genesis, no olvide habilitar la caché de fragmentos en la configuración de W3 Total Cache.

Como ahora está utilizando Cloudlfare como CDN, puede utilizar un complemento como ' Imagify ' o ' Compress JPEG & PNG images ' de TingPNG para comprimir sus imágenes. Ambos son complementos gratuitos disponibles en el repositorio de complementos de WordPress.org. Además, Imagify admite el poderoso algoritmo de compresión con pérdida.

Finalmente, instale el complemento ' Eliminar cadenas de consulta de recursos estáticos ' del repositorio de WordPress para que elimine las cadenas de consulta de recursos estáticos como archivos CSS y JS. Esto se debe a que algunos servidores proxy de almacenamiento en caché no almacenan en caché los recursos con un "?" O "&" en la URL (recuerde, Cloudflare también es un servidor proxy de almacenamiento en caché).

Luego instale ' Usar las bibliotecas de Google el complemento '. Este complemento permite que su sitio de WordPress use la CDN API de la biblioteca AJAX de Google en lugar de servir estos archivos directamente desde su instalación de WordPress.

Algunos de los beneficios son:

• Aumenta la posibilidad de que un usuario ya tenga estos archivos en caché.
• Elimina la carga adicional de su servidor.
• Utiliza versiones comprimidas de las bibliotecas (cuando están disponibles).
• Los servidores de Google están configurados para negociar la compresión HTTP con el navegador solicitante.

Por último, pero no menos importante, use el complemento ' WP-Optimize ' de Ruhani Rabin para limpiar y optimizar su base de datos.

Espero que esto responda a su pregunta con respecto a la optimización de WordPress para reducir la carga del servidor.