Sacando chispas a WordPress sacada de Crunchify
La verdad es que me sorprendió el interés que despertó una de las entradas de la semana pasada, 13 cosas que debes cambiar inmediatamente en tu WordPress. Resulta que hay gente que lee este blog. Y de alguna manera me quedé con ganas de explicar algún truquillo más que suelo aplicar, pero me resultaba difícil poder encasillarlo como “muy básico, que tu abuela pueda entenderlo”. Hoy venimos con esas. Cometeré la osadía de intentar demostrar que las segundas partes no tienen porqué desmerecer a las primeras. A ver qué te parecen los 6 trucos para forzar tu WordPress al límite.

Las páginas dinámicas como las que genera WordPress, por definición, requieren de procesamiento por parte del servidor web. Cuando tratamos de optimizar los recursos, lo que intentamos precisamente es evitar esa sobrecarga, convirtiendo el contenido dinámico en estático. Intentamos que sea lo más estático posible para evitar cualquier cálculo que sature nuestros servidores. Esta entrada va sobre eso. Sobre cómo buscar un compromiso entre la cantidad de lectores que tenemos o esperamos tener, la frescura o dinamismo del contenido que debemos servir y la capacidad de respuesta de los recursos de los que disponemos para saciar a nuestros visitantes.

La configuración que propongo son sólo algunas de las técnicas utilizadas para maximizar la cantidad de lectores que nuestra web puede soportar, utilizando los mínimos recursos necesarios.

Utilizaré un lenguaje plano y sencillo, para que nadie se pierda. Por favor, puristas de los tecnicismos, sed permisivos.

1. Opcode caché

Tratando de simplificar al máximo, cuando un archivo PHP se ejecuta el proceso es el siguiente:

  1. análisis
  2. compilación
  3. ejecución.

Sin reparar demasiado en explicaciones, el opcode caché consiste en cachear scripts PHP compilados en bytecode. De esta forma evitamos los dos primeros pasos, con el coste y retardo que conlleva cada uno de ellos. Si os preguntáis por el beneficio de hacer esto, es muy sencillo: brutal. La diferencia de rendimiento es de entre un x2 y un x10 respecto a no utilizarlo. La única pega, es que generalmente, los servidores compartidos no lo ofrecen. La mayoría de veces se suele necesitar un servidor dedicado, y sí amigo, es más caro.

Aun con ese handicap, es un punto muy a tener en cuenta en nuestro objetivo de forzar nuestra web hasta límites incómodos.

Para los que tenéis servidor dedicado, esto va a la linea de comandos:

sudo apt-get install php-apc

 

#2. Caché de navegador

Otro fundamental. Consiste en configurar nuestro servidor web de tal manera que indique al navegador con qué frecuencia cambia el contenido. En el caso de fotos, audio, video o cualquier contenido multimedia, el archivo en sí no cambia nunca. No se genera dinámicamente. La foto aurken.jpg siempre será la misma imagen. Cuando actualizamos el contenido multimedia, añadimos nuevas fotos con nuevos nombres, pero el archivo aurken.jpg queda intacto. Esto permite que podamos indicar al navegador del usuario que el contenido es para siempre. Que una vez lo cargue en la web, siempre utilice la misma versión.

Como parece lógico, esto influye notablemente tanto en el tiempo de carga de la página como en la utilización de recursos, siempre limitados. Hace que no haya que descargar todas las imágenes, flv, swf, css, js y demás archivos estáticos una y otra vez. La primera vez que entremos a la web, la página tardará el tiempo que necesite para servir todo el contenido. Pero en las siguientes páginas o visitas, la carga del contenido estático será prácticamente inmediato.

El cambio para indicar a nuestro servidor que actúe de esa manera es el siguiente:

Servidor Apache (la mayoría de servidores compartidos)

<ifModule mod_expires.c>
ExpiresActive On
ExpiresDefault A604800

# Cacheamos durante 28 días
<FilesMatch ".(ico|gif|jpe?g|png|flv|pdf|swf|mov|mp3|wmv|ppt)$">
ExpiresDefault A2419200
</FilesMatch>

<FilesMatch ".(xml|txt|js|css)$">
ExpiresDefault A36000
</FilesMatch>

<FilesMatch ".(php|cgi|pl|html|htm)$">
ExpiresDefault A0
</FilesMatch>
</ifModule>

# Headers
<ifModule mod_headers.c>

<FilesMatch ".(ico|gif|jpe?g|png|flv|pdf|swf|mov|mp3|wmv|ppt)$">
Header append Cache-Control "public"
</FilesMatch>

<FilesMatch ".(xml|txt|js|css)$">
Header append Cache-Control "private, must-revalidate"
</FilesMatch>

# Sin caché los archivos PHP y HTML
<FilesMatch ".(php|cgi|pl|html|htm)$">
Header set Cache-Control "no-store, no-cache, must-revalidate, max-age=0"
Header set Pragma "no-cache"
</FilesMatch>
</ifModule>

Basta con incluir esas lineas al final del archivo .htaccess del directorio raíz y conseguiremos lo que buscamos.

Servidor Nginx

# Cacheamos durante 30 días las siguientes extensiones
location ~* \.(?:ico|gif|jpe?g|png|flv|pdf|swf|mov|mp3|wmv|ppt)$ {
log_not_found off;
expires 30d;
add_header Pragma public;
add_header Cache-Control "public, must-revalidate, proxy-revalidate";
}

 

#3. Output caché

Cuando cargamos una página cualquiera, el contenido dinámico se suele obtener de una base de datos. WordPress utiliza la base de datos relacional MySQL para el cometido. Eso significa que cada usuario que entra en la web, exige resultados a la base de datos. Y la base de datos, cuando se le pide demasiado, sufre. En este punto lo que buscamos es aliviar, casi eliminar el dolor de MySQL. Y cortamos por lo sano.

Al acceder a una página, ésta carga principalmente un archivo HTML que previamente ha sido generado por PHP. Y junto a este archivo, se cargan las fotos y recursos que necesitamos para acabar de dar la imagen y aspecto final a la página.

Para la tarea utilizamos WP Super Cache, que aporta notables resultados. WP Super Cache se encarga de guardar en caché páginas dinámicas. Convierte una página generada dinámicamente en un archivo HTML estático. “Supervisa” los posts, comentarios y demás cambios que se dan en el contenido. Cuando el contenido cambia, WP Super Cache borra la versión anterior generando una nueva. Hasta que detecta un nuevo cambio, servirá el contenido como si se tratara de un HTML estático. Éste es su gran beneficio. No sólo evita el procesamiento sino que quita del medio a PHP. No se procesa código PHP alguno.

 

#4. Compresión GZIP, mod_deflate

El contenido, como cualquier archivo virtual tiene un tamaño. Al transferir ese contenido por Internet, cuanto menor sea el tamaño mejor. Para eso utilizamos la compresión. Como su nombre indica, comprime la información para que sea más rápido y evidentemente, más compacta.

Servidores Apache (añadir al final del archivo .htaccess)

# Compresión GZIP
<ifModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/xml text/css text/plain
AddOutputFilterByType DEFLATE image/svg+xml application/xhtml+xml application/xml
AddOutputFilterByType DEFLATE application/rdf+xml application/rss+xml application/atom+xml
AddOutputFilterByType DEFLATE text/javascript application/javascript application/x-javascript application/json
AddOutputFilterByType DEFLATE application/x-font-ttf application/x-font-otf
AddOutputFilterByType DEFLATE font/truetype font/opentype
</ifModule>

Servidores Nginx

# Habilitar compresión GZIP
gzip on;
gzip_disable "msie6";

gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_min_length 1100;
gzip_buffers 16 8k;
#gzip_http_version 1.1;
gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;

 

#5. Combinar archivos js, css

Cada archivo que se carga para mostrar una página supone una petición de respuesta por parte del servidor. Por lo general, al organizar el código, utilizar plugins o añadir librerías, solemos acabar cargando 5 archivos javascript y otros tantos css. Y eso, significa 10 peticiones. Para ser más incisivo, sobran 8. No necesitamos más que un archivo con todo el código javascript y otro con el código css. Ahora bien, imagina esto con 100 personas clickeando en tu web y generando un 500% de carga. ¿No habíamos quedado que teníamos recursos limitados?

Podemos solucionar esto a mano (lo tenía que comentar para los valientes) o a través de un buen plugin, como WP Minify. Su instalación no tiene mayor misterio.

Actualización 14 Octubre 2014: Nos comenta Ivan, que han dejado de actualizar este plugin. Tanto WP Minify Fix como Better WordPress Minify pueden ser buenas alternativas.

 

#6. Subdominios para archivos estáticos

En la mayoría de webs modernas, se guarda información referente al usuario. Son las famosas cookies, importantes para generar el contenido de la web, pero no para mostrar archivos estáticos. Recordemos que los archivos como imágenes, audio, video, etc no cambian. Es decir, la información de las cookies no les sirve para nada, es inútil. El problema es que las cookies se envían a través de todo el dominio. Por eso se hace lo siguiente:

  • www.aurken.net crea cookies que estarán disponible en cualquier página del subdominio www.
  • assets.aurken.net sirve contenido estático en el subdominio assets, sin cookies. Desde aquí se servirán todas los archivos estáticos de WordPress y el theme en cuestión.
  • uploads.aurken.net sirve el contenido estático de la carpeta /wp-content/uploads/ bajo el subdominio uploads, también sin cookies.

Con esto conseguimos que el navegador del usuario no descargue innecesariamente las cookies de los archivos estáticos. El impacto real se ve cuando al cargar una página hay 10 imágenes, y 10 archivos css/js/video/audio. Nos estaríamos ahorrando las 20 cookies que irían asociadas a cada uno de los archivos.

Lo mismo, permite maximizar los recursos de los que disponemos para que nuestro WordPress esté siempre en plenas facultades para responder ante cualquier petición.

Estos cambios deberían ser suficientes para empujar a tu WordPress hacia los límites de tu servidor. Y funcionan, creedme que sí. Al menos lo suficiente como para servir a cientos (literalmente) de usuarios concurrentes. O por ejemplo 8000 likes, 650 tweets y 20.000 visitas en 24 horas, con picos de 500 usuarios simultáneos. Todo ello en un servidor compartido de 3€ al mes.

Lo ideal aún así, sería que estas soluciones no fueran suficientes para tu WordPress. Estaríamos hablando entonces de un bendito problema.

Thanks! I promise to only send relevant stuff to your inbox.

Join the discussion 22 Comments

  • Jon Urkiola says:

    S-U-B-L-I-M-E!

  • Ander says:

    Y puesto a optimizar, lo mismo con el servidor web (Apache2) sin en vez de usar .htaccess lo ponemos todo el un VirtualHost. Para cambios duraderos, como pueden ser lo cacheos, mejor no usar .htaccess ya que se lee en cada petición.

  • Aurken says:

    Buen apunte Ander!

    Lo explico con .htaccess por cómo suele utilizar la gente WordPress, mayoritariamente servidores compartidos con apenas acceso y posibilidades.

    Thanks 🙂

  • jgarteiz says:

    Leer "lenguaje plano y sencillo"
    +
    Leer en la siguiente línea "el opcode caché consiste en cachear scripts PHP compilados en bytecode"
    =
    Este blog me supera*

    *Así que ya sabes, subiré con dudas!!!
    Gracias por el post 😉

  • munikes says:

    Aleluyahhhh!!! Estaba buscando un resumen asi para nginx.
    1000 gracias socio

  • blogger says:

    Excelente pieza!!, me ayudó mucho

    Muchas gracias y un saludo

  • Photoshop Disasters. says:

    ¡Qué pasada de foto tío!

  • plegado chapa says:

    Es genial, desde que os recibo no puedo parar de mirar todas vuestras sugerencias y me alegra cuando recibo uno más, sois lo mejor en español, me encata vuestra presentación y el curre que hay detrás. Un beso y abrazo,GRACIAS POR VUESTRO TRABAJO, nos alegrais la vida.

  • lampista says:

    Aporte valioso. Me encanta tu web.

  • elreparadon says:

    ¡Muy practico! Contundentes motivos. Manten este espiritu es un articulo fantastico. Tengo que leer màs articulos como este.

    Saludos

  • osteopata says:

    Hola, ¿Estás utilizando wordpress para tu plataforma web? Soy nuevo en el mundo de los blogs, pero estoy tratando de empezar y crear el mio propio. ¿Se necesita tener algun conocimiento de HTML para hacer tu blog? Te agradeceria cualquier ayuda.

    Saludos

    • Aurken says:

      Sí, utilizo WordPress. En principio no hace falta conocer HTML aunque es cierto que es conveniente. Cualquier cosilla no dudes en preguntar.

      Saludos!

  • diseñoreus says:

    He estado googleando un poco por artículos de alta calidad o entradas en webs sobre estos temas. Explorando en Google por fin encontré este sitio web. Con lectura de esta post, estoy convencido que he encontrado lo que estaba buscando o al menos tengo esa extraña sensacion, he descubierto exactamente lo que necesitaba. ¡Por supuesto voy hacer que no se olvide este sitio web y recomendarlo, os pienso visitar regularmente.

    Saludos

  • Ivan says:

    Gran artículo.
    Sólo comentar que aconsejas utilizar el plugin wp minify, pero este està un poco desactualizado. Si entras a descargar plugin hay una nota que dice:

    "This plugin hasn't been updated in over 2 years. It may no longer be maintained or supported and may have compatibility issues when used with more recent versions of WordPress."

    ¿Dispones de alguna alternativa?

    Gracias.

  • Adanc says:

    Que sucede como en mi caso que estaríamos hablando de un bendito problema.

    Your website is slower than 80% of all tested websites

    Y mis capacidades en este campo las siento superadas ya que no soy un master en la materia y todos los tutoriales que he leido no me dan algun resultado positivo. Que recomiendas … ?

  • Ideas says:

    Muchas gracias!! no solo he aplicado estas cosillas sino que a 2015 he podido comprobar las mejoras en Inside de google, como se han ido mejorando estas cosillas que me marcaba como error, asi que totalmente actual, saludos

  • marcos says:

    Hola,
    he seguido los puntos que indicas en este post… pero no he tenido la misma suerte que otros usuarios 🙁

    Me gustaría mejorar el resultado de google page speed, sobre todo para la versión mobile.

    He abierto htaccess, he añadido las lineas que comentas en el punto 2 y 4, he vuelto a subirlo.
    La home page funciona, pero si cambio de página me da error 404.
    The requested URL /unitrips-wp/paquetes-experiencias/ was not found on this server.

    Si vuelvo a poner el antiguo htaccess funciona todo bien.

    Sobre el minify, si lo instalo y lo activo me descoloca toda la página, así que he vuelto a desinstalarlo.

    El wp caché lo tengo activo… pero no mejora el google speed insight. 🙁

  • Humor says:

    Gracias muy utiles los tips de worpress!

  • reformar integral says:

    Esto es ¡genial! No he leído algo como esto antes . Es agradable encontrar a alguien con algunas ideas originales sobre este tema. Esta web es algo que se necesita en la blogoesfera , alguien con un poco de dominio. Un trabajo útil para traer algo nuevo a Internet. Gracias de todos lo que te leemos.

  • Me ha gustado todo, gran articulo.

Leave a Reply

Aurken Bilbao Random thoughts and small learnings