El quedarse corto o pasarse, significará el desaprovechar recursos, quitándoselos a otras tareas o quedarse corto y que el servidor vaya muy lento e incluso caiga.

Quizás es una de las tareas más tediosas que hay.

He estado buscando durante mucho tiempo algo que me facilitara la vida para optimizar MySQL tanto en mis servidores como en los VPS, Servidores Híbridos y Dedicados de mis clientes.

Normalmente, hay que ir haciendo ajustes en estos para que estén al 100%, no es realizarlo una vez y te olvidas de por vida. SI las necesidades de estos disminuyen o aumentan, hay que ajustarlos de nuevo.

La pesadilla, siempre a sido referente a MySQL.

Después de buscar mucho tiempo, he encontrado un script que es una auténtica maravilla.

El script lo encontrareis en esta página:

http://www.day32.com/MySQL/

Si tenis un VPS o Dedicado, os facilitará la vida muchísimo.

Las instrucciones que voy a dar, son referentes a una instalación en CentOS.

Sirve si tenéis instalado cPanel en él.

Lo primero que deberemos hacer es acceder al servidor por SSH

Una vez que estemos conectados, escribimos:

wget http://www.day32.com/MySQL/tuning-primer.sh

Con esto, nos descargaremos el script

Para que funcione bien este script, deberemos tener instalado bc, por lo tanto, escribiremos:

yum install bc

Lo anterior nos instalará bc.

Una vez que lo tengamos instalado, escribimos:

sh tuning-primer.sh

Debemos estar en el mismo directorio que el archivo.

El script se pondrá en marcha.

Os aconsejo que abráis otra conexión SSH, de esta forma, en una tendréis el script y en la otra podremos configurar MySQL.

Cuando el script finalice, os mostrará algo así (os pongo una imagen, ya que es mucho más clarificadora por los colores):

Y aquí el texto completo que nos muestra:

-- MYSQL PERFORMANCE TUNING PRIMER --
- By: Matthew Montgomery -

MySQL Version 5.0.90-community x86_64

Uptime = 0 days 14 hrs 6 min 16 sec
Avg. qps = 2
Total Questions = 102107
Threads Connected = 2

Warning: Server has not been running for at least 48hrs.
It may not be safe to use these recommendations

To find out more information on how each of these
runtime variables effects performance visit:

http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html

Visit http://www.mysql.com/products/enterprise/advisors.html
for info about MySQL's Enterprise Monitoring and Advisory Service

SLOW QUERIES
The slow query log is NOT enabled.
Current long_query_time = 10 sec.
You have 4 out of 102128 that take longer than 10 sec. to complete
Your long_query_time seems to be fine

BINARY UPDATE LOG
The binary update log is NOT enabled.
You will not be able to do point in time recovery
See http://dev.mysql.com/doc/refman/5.0/en/point-in-time-recovery.html

WORKER THREADS
Current thread_cache_size = 1024
Current threads_cached = 5
Current threads_per_sec = 0
Historic threads_per_sec = 0
Your thread_cache_size is fine

MAX CONNECTIONS
Current max_connections = 100
Current threads_connected = 3
Historic max_used_connections = 8
The number of used connections is 8% of the configured maximum.
You are using less than 10% of your configured max_connections.
Lowering max_connections could help to avoid an over-allocation of memory
See "MEMORY USAGE" section to make sure you are not over-allocating

No InnoDB Support Enabled!

MEMORY USAGE
Max Memory Ever Allocated : 542 M
Configured Max Per-thread Buffers : 400 M
Configured Max Global Buffers : 510 M
Configured Max Memory Limit : 910 M
Physical Memory : 31.37 G
Max memory limit seem to be within acceptable norms

KEY BUFFER
Current MyISAM index space = 73 M
Current key_buffer_size = 250 M
Key cache miss rate is 1 : 58
Key buffer free ratio = 81 %
Your key_buffer_size seems to be fine

QUERY CACHE
Query cache is enabled
Current query_cache_size = 250 M
Current query_cache_used = 14 M
Current query_cache_limit = 4 M
Current Query cache Memory fill ratio = 5.73 %
Current query_cache_min_res_unit = 4 K
Your query_cache_size seems to be too high.
Perhaps you can use these resources elsewhere
MySQL won't cache query results that are larger than query_cache_limit in size

SORT OPERATIONS
Current sort_buffer_size = 1 M
Current read_rnd_buffer_size = 768 K
Sort buffer seems to be fine

JOINS
Current join_buffer_size = 1.00 M
You have had 11 queries where a join could not use an index properly
You should enable "log-queries-not-using-indexes"
Then look for non indexed joins in the slow query log.
If you are unable to optimize your queries you may want to increase your
join_buffer_size to accommodate larger joins in one pass.

Note! This script will still suggest raising the join_buffer_size when
ANY joins not using indexes are found.

OPEN FILES LIMIT
Current open_files_limit = 8302 files
The open_files_limit should typically be set to at least 2x-3x
that of table_cache if you have heavy MyISAM usage.
You currently have open more than 75% of your open_files_limit
You should set a higher value for open_files_limit in my.cnf

TABLE CACHE
Current table_cache value = 4096 tables
You have a total of 13106 tables
You have 4096 open tables.
Current table_cache hit rate is 6%
, while 100% of your table cache is in use
You should probably increase your table_cache

TEMP TABLES
Current max_heap_table_size = 32 M
Current tmp_table_size = 32 M
Of 1472 temp tables, 43% were created on disk
Perhaps you should increase your tmp_table_size and/or max_heap_table_size
to reduce the number of disk-based temporary tables
Note! BLOB and TEXT columns are not allow in memory tables.
If you are using these columns raising these values might not impact your
ratio of on disk temp tables.

TABLE SCANS
Current read_buffer_size = 1 M
Current table scan ratio = 32 : 1
read_buffer_size seems to be fine

TABLE LOCKING
Current Lock Wait ratio = 1 : 696
You may benefit from selective use of InnoDB.
If you have long running SELECT's against MyISAM tables and perform
frequent updates consider setting 'low_priority_updates=1'
If you have a high concurrency of inserts on Dynamic row-length tables
consider setting 'concurrent_insert=2'.

Cómo podéis ver, lo que hace es hacer un estudio de como ha estado funcionando MySQL y da consejos sobre parámetros que debemos tocar.

Una vez que nos muestra el resultado, deberemos realizar las modificaciones aconsejadas por el script.

Para ello, en la otra ventana que tenemos una conexión activa SSH escribimos:

cp /etc/my.cnf /etc/my.cnfBACKUP

Con lo anterior realizamos una copia de seguridad que no está de más.

vi /etc/my.cnf

Esto nos abrirá el archivo de configuración de MySQL.

Lo abro con vi, ya que es el que más me gusta, pero podéis realizar las modificaciones con el que más os guste.

Una vez abierto, para los que no estén familiarizados con vi, debéis apretar en el teclado la tecla “Insert”, de esta forma podréis escribir en el archivo.

Realizar las modificaciones que os aconseje el script.

Una vez que las hayáis realizado, apretar el botón “Escape” y escribir:

:w

Esto guardará las modificaciones.

Una vez realizadas las modificaciones, apretar:

:q

Lo anterior os sacará del editor.

Una cosa importante, ya que hay veces que sucede.

Si borras más cosas de la cuenta y no sabes que has borrado, lo mejor es que salgas sin guardar. Para salir sin guardar debéis escribir:

:q!

Acordaros de apretar la tecla “escape” antes, o no tendrá efecto, estaréis escribiendo el el archivo.

Una vez que hayáis realizado los cambios y los hayáis guardado, hay que reiniciar el servidor MySQL.

Si usáis WHM/cPanel, ir a WHM y en “Restart Services” Apretar sobre “SQL Server (MySQL)”

Si no usais WHM, escribir en la consola:

/etc/init.d/mysqld restart

Si MySQL no reinicia, algo habéis hecho mal en el archivo de configuración.

Para resolverlo y que no nos caigan gotas de sudor, escribimos:

rm –rf /etc/my.cnf

cp /etc/my.cnfBACKUP /etc/my.cnf

y volvemos a reiniciar.

Si no habíamos cometido ningún error, casi con toda seguridad la página os irá mucho más fluida.

Ahora, esperáis de 24 a 48h y volvéis a poner en marcha el script y veis resultados.

Si todo sale Ok, perfecto, si os sale algún otro consejo, pues volvéis a realizar el proceso.

ADVERTENCIA: Este tutorial, quizás, no es para todo el mundo. Muchos pasos los podrás realizar sin ningún problema, pero en otros, es necesario un conocimiento más avanzado.

La Biblia de la Optimización de WordPress

Este tutorial de WordPress es quizás  la guía más completa de optimización de WordPress creado hasta el momento, con una gran colección de consejos sobre cómo acelerar tu sitio.

Si alguna vez has experimentado un panel de administración de WordPress lento,mensajes que  ”ha caído el servidor MySQL”,  las páginas tardan una eternidad en cargar o si deseas preparar tu sitio para un importante aumento en el tráfico (por ejemplo llegas a la primera página de Digg) esta es la guía que estabas buscando.

1. Comprueba las estadísticas de tu web

Lo que suele suceder, en sitios con problemas de carga lenta es, simplemente,  el tamaño de la página. Hoy día, mucha gente coloca en sus páginas imágenes, flash, videos y mucho javascripts que necesita de ancho de banda para cargarse.

Si desea empezar a abordar esta cuestión con seriedad, lo que necesitas en primer lugar el navegador Firefox, la extensión Firebug y el plugin YSlow.

El módulo YSlow te permitirá obtener una puntuación de rendimiento de 0-100. Tu sítio debería obtener 80 o más, ese será nuestro objetivo.

Trata de tener páginas de 100 kb como máximo. Lo ideal serían páginas por debajo de 50kb. Si tienes una gran cantidad de contenido multimedia, intenta por todos los medios aprender a usar YSlow.

Más información sobre las formas de mejorar la velocidad de carga de la página.

2. Revisa tu SO Windows Vista

En raras ocasiones en que estás cargando con lentitud tu sitio y otros sitios, puede ser por tu sistema de Windows Vista.

Si está ejecutando Vista comprobar este artículo para obtener un diagnóstico y posibles soluciones.

3. Comprobar los Plugins

Los plugins son generalmente el principal sospechoso de la baja velocidad de carga. Con tantos plugins de WordPress, podría ser que hubieramos instalado un plugin que no utilizara los recursos de manera óptima.

Por ejemplo plugins que causaban en el pasado problemas de carga eran Popularity contest, aLinks o @Feed.

Para comprobar los plugins, desactivar todos ellos y comprobar las áreas críticas de nuevo. Si todo va bien, volver a habilitar los plugins uno a uno hasta encontrar el plug-in problemático.

Después de encontrar el causante, puedes escribir un mensaje al autor del plugin y esperar a que lo arregle o buscar una alternativa.

4. Revisa tu Theme

Si los plugins no son los culpables de la lentitud de la página, debes comprobar el Theme que usas.

Los temas pueden incluir código con capacidads de plugin dentro de archivo function.php. De modo que, todo lo que se aplica a los plugins, se pueden aplicar al theme.

Además, los themes pueden utilizar JavaScript excesivo o archivos de imagen, lo que provoca una carga lenta de la página a causa de gran cantidad de datos a transferir y / o el número de peticiones HTTP utilizadas.

Con WordPress, viene un theme predeterminado. Utilízalo para comprobar si el culpable es el theme que usas.

Si descubres que el causante de la lentitud de carga es el theme que usas, puede utilizar la herramienta Firebug. Excelente herramienta para el navegador Firefox, te ayudará a depurar el problema.

También puedes utilizar este sitio para obtener información general sobre tu sitio de forma muy rápido.

5. Optimizar las Tablas de la base de datos

Debes optimizar las Tablas de base de datos  periódicamente (y reparar si es necesario) para un rendimiento óptimo.

Yo recomiendo usar el plugin WP-DBManager que proporciona esta funcionalidad, así como copia de seguridad de base de datos, que son clave para cualquier instalación de blog.

WP-DBManager te permite programarlo y olvidarte, y se encargará de todo el trabajo de forma automatizada. (si lo deseas, te enviará la base de datos cada día a tu email)

Otra alternativa,  es realizar el proceso de forma manual, optimizando y reparando las Tablas a través de una herramienta como phpMyAdmin.

6. Desactiva las revisiones de las Entradas (post)

Con WordPress 2.6 y posteriores, apareció lo que se denominó, “Revisiones de la Entrada”. Un seguimiento de la entrada de forma automatizada. Cada vez que “Guardamos” una modificación, la revisión se escribe en la base de datos. Si no necesita esta función, puedes desactivarla mediante la adición de una línea a tu archivo wp-config.php, que se encuentra en el directorio de instalación de tu sitio de WordPress:

define('WP_POST_REVISIONS', false);

Si has tenido esta opción activa en tu blog durante un tiempo, tendrás gran cantidad de puntos de restauración de las entradas. Si deseas eliminar las revisiones, simplemente ejecuta esta consulta (por ejemplo, utilizando el mencionado plugin WP-DBManager).

DELETE FROM wp_posts WHERE post_type = "revision";

Esto eliminará todos los “revision” de las Tablas de la base de datos, por lo que reducirás su tamaño considerablemente.

ADVERTENCIA: Haz esto con cuidado. Si no estás seguro de lo que está haciendo, asegúrate de realizar una copia de seguridad de la base de datos o, mejor aún, pide ayuda profesional.

7. Implementar el almacenamiento en caché

El almacenamiento en caché es un método de recuperación de datos desde un subdirectorio preparado (cache) en lugar de utilizar los recursos para generar cada vez la misma información que se necesita. El uso de la caché, acelera considerablemente la carga de las páginas y por regla general se usa en todas las aplicaciones más modernas.

La forma más fácil de implementar el almacenamiento en caché (y por lo general la única forma si tu blog está en un alojamiento compartido) es utilizar un plugin caché.

El más utilizado es el WP Super Cache.

Un nuevo niño en la familia, W3 Total Cache, que es la alternativa más potente, y cada día madura.

8. Optimización de MySQL

MySQL puede guardar los resultados de una consulta en su caché propio. Debes editar el fichero de configuración de MySQL (normalmente /etc/my.cnf) y agregar estas líneas:

query_cache_type = 1
query_cache_limit = 1M
query_cache_size = 16M

Esto creará un caché de 16 MB después de reiniciar el servidor MySQL (la cantidad depende de la cantidad de RAM disponible, yo uso alrededor de 250 MB de 4GB ).

Para comprobar si está funcionando correctamente, ejecuta esta consulta:

SHOW STATUS LIKE 'Qcache%';

Ejemplo de resultado:

Qcache_free_blocks
718


Qcache_free_memory
13004008


Qcache_hits
780759


Qcache_inserts
56292


Qcache_lowmem_prunes
0


Qcache_not_cached
3711


Qcache_queries_in_cache
1715


Qcache_total_blocks
4344

MÁS OPTIMIZACIONES PARA MYSQL:

Hay un montón de opciones con las que puedes jugar, aquí está mi archivo de configuración MySQL, funcionando para 4GB, quad-core.

Esto no tiene porqué irte bien a ti, es solo una orientación general.

[mysqld]
bulk_insert_buffer_size = 8M
connect_timeout=10
interactive_timeout=50
join_buffer=1M
key_buffer=250M
max_allowed_packet=16M
max_connect_errors=10
max_connections=100
max_heap_table_size = 32M
myisam_sort_buffer_size=96M
query_cache_limit = 4M
query_cache_size = 250M
query_cache_type = 1
query_prealloc_size = 65K
query_alloc_block_size = 128K
read_buffer_size=1M
read_rnd_buffer_size=768K
record_buffer=1M
safe-show-database
skip-innodb
skip-locking
skip-networking
sort_buffer=1M
table_cache=4096
thread_cache_size=1024
thread_concurrency=8
tmp_table_size = 32M
wait_timeout=500

# for slow queries, comment when not used
#log-slow-queries=/var/log/mysql-slow.log
#long_query_time=1
#log-queries-not-using-indexes

[mysqld_safe]
nice = -5
open_files_limit = 8192

[mysqldump]
quick
max_allowed_packet = 16M

[myisamchk]
key_buffer = 64M
sort_buffer = 64M
read_buffer = 16M
write_buffer = 16M

9. PHP Cache

PHP es un lenguaje interpretado, lo que significa que se inicia cada vez con el código PHP. Este proceso de compilación puede ser almacenado en caché con la instalación de un caché de código de operación, tales como eAccelerator. Hay otras soluciones de almacenamiento en caché.

Para instalar eAccelerator, descomprime el archivo y ves a la carpeta eAccelerator. A continuación, escribe:

phpize
./configure
make
make install

Esto instalará eAccelerrator.

Después hay que crear la carpeta temporal para el almacenamiento:

mkdir /var/cache/eaccelerator
chmod 0777 /var/cache/eaccelerator

Por último, hay que añadir estas líneas al final de tu archivo php.ini (generalmente /etc/php.ini o /usr/lib/php.ini):

extension="eaccelerator.so"
eaccelerator.shm_size="16"
eaccelerator.cache_dir="/var/cache/eaccelerator"
eaccelerator.enable="1"
eaccelerator.optimizer="1"
eaccelerator.check_mtime="1"
eaccelerator.debug="0"
eaccelerator.filter=""
eaccelerator.shm_max="0"
eaccelerator.shm_ttl="0"
eaccelerator.shm_prune_period="0"
eaccelerator.shm_only="0"
eaccelerator.compress="1"
eaccelerator.compress_level="9"

Los cambios se notarán de inmediato, ya que PHP no tiene por qué ser reiniciado.

Nota 1: WP Super Cache y eAccelerator trabajan juntos muy bien, consiguiendo un gran redimiento.
Nota 2: Si te gusta probar más potencia en la conjunción de WP Super Cache y eAccelerator mira esta página.
Nota 3: Lamentablemente eAccelerator no funcionará si PHP es ejecutado como CGI. Puedes usar FastCGI que trabajará con suexec y eAccelerator.

10. Optimización del servidor Web

Sobre la optimización de Apache se ha escrito mucho en los libro, pero os voy a recomendar unas páginas, en primer lugar esta página. Para consejos de compilación esta otra, para consejos sobre rendimiento esta, consejos VPS aquí y para consejos de keep alive aquí.

Puede probar fácilmente los cambios en la configuración mediante la ejecución de una prueba en tu línea de comandos

ab -t30 -c5 http://www.tusitio.com/

y comparar los resultados. Tengo alrededor de 200 req/s en un VPS.

Para pruebas más flexible puedes utilizar herramientas como Autobench que trabaja en conjunto con httperf, otra herramienta de evaluación comparativa.

Utiliza un servidor web rápido como nginx para servir contenido estático (es decir, imágenes), mientras que utilizas otro servidor para el contenido dinámico, que es otro truco que se suele usar.

Nota 1: Más recursos interesantes. Optimización del tiempo de carga de página y una serie de tutoriales sobre la mejora del rendimiento web.
Nota 2: Puede encontrar más consejos y trucos en el sitio de Elliot’s Back

11. ”El servidor MySQL ha caido” solución

Este error de base de datos de WordPress aparece en algunas configuraciones y se manifiesta en yendo lento o no hay respuesta, por lo general en su página de administración.

La Solución para este problema de MySQL se intenta abordar muy bien en este artículo.

Este problema, evidentemente existe, pero la solución propuesta es válida sólo hasta que actualices WordPress. Es de esperar que se seguirá investigando y se añadira una solución en el núcleo de WordPress en un futuro.

Nota: Hay veces que dando a wait_timeout un valor de 1000 es suficiente.

12. Problema de imposibilidad de envío de Entradas

Si estás experimenta problemas en el panel de administración de WordPress, con la imposibilidad de publicar o actualizar algunas entradas, es probable que te estés dando de lleno contra mod_security.

ModSecurity es el módulo de Apache para aumentar la seguridad del sitio web mediante la prevención de intrusiones en el sistema. Sin embargo, a veces, puede decidir que WordPress está realizando consultas de MySQL sospechosas y las introduce en la lista de negra, lo cual se manifiesta con lentitud o falta de respuesta del sitio.

Para probar si este es el caso, revisa tu registro de errores de Apache, por ejemplo:

tail -f /usr/local/apache/logs/error_log

y buscar algo como esto:

ModSecurity: Access denied with code 500 (phase 2) ... [id "300013"] [rev "1"] [msg "Generic SQL injection protection"] [severity "CRITICAL"] [hostname  www.prelovac.com"] [uri "/vladimir/wp-admin/page.php"

Nos dice que el acceso a esta página fue negado a causa de una regla de seguridad con ID 300013. Para arreglarlo, debemos introducirlo en la lista blanca.

Para ello, edita el archivo de configuración de Apache (por ejemplo /usr/local/apache/conf/modsec2/exclude.conf) y agrega estas líneas:

SecRuleRemoveById 300013

Esto añadirá la página a la lista blanca de seguridad y tu sitio seguirá trabajando con normalidad.

13. Pings RSS y Pingbacks

Otra razón para la lentitud de WordPress puede ser el ping RSS y tiempo de espera para pingback.

WordPress, por defecto, intente hacer ping a los servidores que aparecen en tu lista de ping (que se encuentra en Opciones-> Escritura) y uno de ellos puede retrasar el proceso.

La segunda razón son pingbacks, mecanismo en el que notifica a los sitios que has enlazado en tu entrada. Puedes desactivarlo en Preferencias-> Discusión “Tratar de notificar a todos los blogs enlazados en la entrada (hace más lenta la publicación)”.

Prueba la lista de pings  y ha desactivar el pingbacks para ver si ayuda a acelerar sel tiempo de espera.

Lo siguiente, son las reglas generales para optimizar el tiempo de carga de las páginas

14. Subdominios, pueden ser utilizados para compartir la carga

La mayoría de los navegadores están configurados para cargar 2-4 archivos de un dominio en paralelo. Si mueves algunos archivos a un dominio diferente (subdominio) el navegador comenzará a descargarse en paralelo varios archivos (de 2 a 4).

Es buena idea mover los archivos de imagenes a un subdominio que crees. Por ejemplo, puedes colocar todas tu imagenes de diseño en un subdominio y mediante la hoja css realizar las peticiones para que las descargue del subdominio.

15. Minimizar el número de peticiones HTTP

Puedes disminuir el número de peticiones HTTP utilizando menos imágenes (o colocando todas las imágenes en una imagen de gran tamaño e ir posicionandola mediante CSS), utilizando menos  javascript, menos archivos css (por lo general, esto significa menos plugins).

Se ha realizado un gran esfuerzo con el plugin PHP speedy. Este Plugin fusiona todos los todos los archivos JavaScript y CSS en un gran archivo que ayuda ayuda a reducción drásticamente el números de solicitudes HTTP. El mayor inconveniente de PHP Speedy es que no es 100% compatible con todos los plugins.

También podría ser interesante utilizar CSS Sprite generator para mover todas tus imágenes en una sola imagen y luego usar la posición de fondo en CSS para mostrarlas. Esto reducirá el número de peticiones HTTP de forma significativa.

16. Comprimir el contenido usando Apache. Htaccess

Si tienes tu propio servidor, podrá seleccionar la utilización de gzip para enviar el contenido a los navegadores. Esto reducirá significativamente el tiempo de carga, la mayoría de páginas HTML se comprimen bien.

Si quieres probarlo, añade este código a tu htaccess.

AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css application/javascript application/x-javascript application/x-httpd-php application/rss+xml application/atom_xml text/javascript

17. Crear cabeceras de expiración

Los encabezados de expiración, son muy interesantes para decirle a los navegadores si deben utilizar la cache o no, y durante cuanto tiempo. La mayoría de las imágenes de un sitio nunca cambian y es una buena idea que se mantengan en la cache local de los usuarios.

Una posible configuración recomendada sería esta.

Header unset Pragma
FileETag None
Header unset ETag

# 1 year

Header set Cache-Control "public"
Header set Expires "Thu, 15 Apr 2010 20:00:00 GMT"
Header unset Last-Modified

# 2 HOURS

Header set Cache-Control "max-age=7200, must-revalidate"

# CACHED FOREVER
# MOD_REWRITE TO RENAME EVERY CHANGE

Header set Cache-Control "public"
Header set Expires "Thu, 15 Apr 2010 20:00:00 GMT"
Header unset Last-Modified

Puedes comprobar la configuración de tu cache aquí.

18. Cache para Gravatar

Muchos blogs usan Gravatar, las pequeñas imágenes al lado de los comentarios. Sin embargo Gravatars tiene dos grandes defectos en cuanto a la optimización de su sitio:

Cada imagen Gravatar, ejecuta una nueva petición  HTTP, incluso si ya ha sido descargada la imagen en algún comentario anterior en la misma entrada (entradas que contengan 100 comentarios se producen 100 solicitudes HTTP)

Las Imágenes Gravatar no caducan.

Lo que podemos hacer es crear una caché para Gravatar de forma local, donde las imágenes se almacenan en caché y sirve para nuestro sitio. Lo ideal sería colocar la caché para Gravatar en un subdominio separado (véase el primer apartado).

Puedes usar un plugin como Zenpax.com que permite almacenar todas las imágenes Gravatars en una caché local.

19. Optimizar las imágenes con smush.it

A menudo, se pasa por alto que las imágenes pueden ser optimizadas (que tengan menos peso). Esto reduce significativamente los tiempos de carga.

¿No sería perfecto si pudieras abrir un sitio, pulsar un botón en su navegador y recibir todas las imágenes de tu sitio optimizadas y listas en un único archivo zip?. Pues es posible gracias a smush.it y su plugin para Firefox. Es increíble lo fácil y potente que es.

20. CSS en la parte superior, JavaScript en la parte inferior

Esta es  la práctica de oro. Debes colocar tus archivos CSS en la parte superior de la página para que se cargan en primer lugar. Los Archivos JavaScript debe ser colocado en la parte inferior de la página (cuando sea posible). Para ello, tenemos un plugin que realiza exactamente esto, siempre que sea posible, el plugin se llama Footer JavaScript.

Conclusión

Los Servidores web y los sitios web modernos dependen de muchos factores diferentes.

En este tutorial se han reflejado los diferentes enfoques de optimización a nivel de sistema , Apache, PHP y MySQL y cambios en configuración de su WordPress.

fuente prelovac