Hay una serie de formas de mejorar el rendimiento del sitio, estos métodos son relativamente genéricos y no deberían ser una preocupación real en la mayoría de los casos de uso, pero le recomendamos que no los implemente si no los entiende.
Un método sencillo es utilizar los módulos y cabeceras caducados de apache para jugar con la caducidad de los archivos cacheados en el lado del navegador, tiene la ventaja de ser utilizable en todo tipo dealojamiento (Compartido, Premium, VDS o Dedicado) :
Para evitar que los navegadores tengan que recargar ciertos archivos estáticos (archivos CSS, imágenes o scripts Javascript, por ejemplo), que a veces se comparten en diferentes páginas del sitio, en cada visita (o cambio de página en el mismo sitio, por ejemplo), es posible dar fechas de caducidad para ciertos archivos/tipos de archivos en el lado del servidor (por defecto, el servidor no da ninguna directiva y es el navegador el que decide solicitar o no el/los archivo/s al servidor y cuándo recargarlos. De este modo, es posible reducir el número de archivos que el navegador del visitante ha solicitado y posiblemente recargado en cada página o visita y, por lo tanto, permitir que el sitio se cargue más rápidamente (especialmente en el caso de una conexión lenta o un sitio con un gran tamaño de archivo).
Puede observar el comportamiento de su navegador (y del servidor) utilizando las herramientas para desarrolladores incorporadas en los navegadores modernos. Si al pasar de una página a otra hay peticiones con el código de respuesta 304 No Modificado (columna de Estado), significa que el navegador ha vuelto a pedir el archivo al servidor pero éste no ha "caducado" o cambiado y no ha hecho que el navegador vuelva a descargar el archivo. Si algunos archivos están en código 200 pero en gris, significa que el navegador ni siquiera pidió el archivo al servidor y directamente mostró el archivo que tenía en su caché.
Para saber si se ha enviado un Etag, o para recuperar la fecha de caducidad de un archivo o página, haga clic en el [+] a la izquierda de la solicitud GET correspondiente y busque en la sección "Respuestas" de la pestaña "Cabeceras"
Podrá ver, por ejemplo, :
Fecha Wed, 30 Mar 2011 16:30:50 GMT Servidor Apache/2.2.17 Última modificación Tue, 29 Mar 2011 23:58:50 GMT Etag "179abc5-5921-49fa7d7758280" Accept-Ranges bytes Cache-Control max-age=172800 Expira Fri, 01 Apr 2011 16:26:03 GMT Vary Accept-Encoding Content-Encoding gzip Contenido-Longitud 5716 Content-Type text/css
Donde podemos ver que se proporciona un Etag (ver más abajo), que la última petición al archivo es del 30/03/2011 a las 16:30, que la última modificación del archivo (lado del servidor) es del 29/03/2011 y que expirará el 01/04/2011 y que no debe permanecer más de 172800 segundos en la caché del lado del cliente (más allá de eso, si no está ya hecho, el navegador lo eliminará de su caché por sí mismo)
Puede utilizar un archivo .htaccess en la raíz del sitio en cuestión añadiendo, por ejemplo, :
FileEtag ninguno
Etag de cabecera no ajustado
ExpiraActivo el
ExpiresByType image/jpg "acceso más 4 días"
ExpiresByType image/gif "acceso más 7 días"
ExpiresByType image/jpeg "acceso más 4 días"
ExpiresByType image/png "acceso más 4 días"
ExpiresByType image/x-icon "acceso más 7 días
ExpiresByType text/css "acceso más 48 horas
ExpiresByType application/javascript "acceso más 48 horas
ExpiresByType application/x-javascript "acceso más 48 horas
ExpiresByType application/x-shockwave-flash "acceso más 48 horas"
ExpiresDefault "acceso más 1 días"
La primera parte (en la directiva FilesMatch) significa que todos los archivos con la extensión .ico, .pdf, .flv... no tendrán un Etag y éste no se transmitirá.
La etiqueta es un identificador creado por el servidor Apache para cada archivo, si éste se modifica la etiqueta cambiará; esto permite al navegador comparar la etiqueta enviada por el servidor con la que tiene en la caché para poder recuperar de nuevo el archivo en caso de diferencia.
El problema es que la cabecera Etag es redundante con la cabecera "Last-Modified" que también envía Apache, esta cabecera al ser precisa al segundo puede no ser suficiente en el caso de archivos dinámicos (archivos generados sobre la marcha por scripts PHP por ejemplo) si han sido modificados más de una vez por segundo pero puede ser inútil en el caso de archivos CSS o Javascript que se modifican pocas veces (y manualmente) por ejemplo
Si Etag está activado, cada vez que se solicite un archivo, el servidor Apache regenerará un Etag comprobando las fechas de última modificación del archivo, su tamaño y su ubicación en el sistema de archivos; esto consumirá recursos y tomará más tiempo que sólo recuperar la fecha de última modificación (que también se proporciona por defecto), también implica que el navegador debe solicitar el Etag, comprobar si coincide con el que tiene en la caché antes de posiblemente solicitar el archivo de nuevo, si los Etags están deshabilitados el navegador no solicitará el archivo si ya lo tiene en la caché y no está "caducado".
También es posible desactivar la cabecera "Last-Modified" añadiendo lo siguiente a la etiqueta FilesMatch: Header unset Last-Modified
Se recomienda probar cuidadosamente el comportamiento del navegador si Etag y Last-Modified están deshabilitados y establecer los tiempos de expiración en consecuencia con mod_expires.
Documentación oficial de mod_headers
En la segunda parte del ejemplo, la directiva ExpiresByType seguida del mimetype se utiliza para definir el tiempo de validez de los archivos de una extensión determinada después del último acceso del usuario. Esto permite que un navegador, por ejemplo, no vuelva a comprobar sus archivos jpg almacenados en caché durante 4 días, "priorizando" los archivos que tienen un tiempo de caducidad más largo sobre los que no lo tienen.
Documentación oficial de mod_expires
Uso de un módulo de caché de PHP
Hay dos tipos principales de caché en PHP:
La caché de la aplicación
La caché de la aplicación está integrada en la aplicación PHP y permitirá no recalcular en cada acceso a una página todo el código, principalmente algunas partes que no cambian en cada acceso (por ejemplo: la maquetación que la mayor parte no cambiará, la inclusión de texto contenido en un archivo que no ha sido modificado desde el último acceso o los cálculos que son recurrentes con parámetros idénticos).
El "resultado" del procesamiento de las partes del código que no cambian se guarda y se retoma directamente la próxima vez que se utilice, evitando así cálculos/accesos al disco innecesarios, y evitando también la necesidad de recuperar ciertos datos del servidor de la base de datos.
La mayoría de los frameworks PHP como Symfony o Zend ofrecen un sistema de caché de forma transparente para el desarrollador/usuario, lo mismo ocurre con la mayoría de los CMS y otras herramientas PHP como PHPBB, Prestashop o WordPress que integran sistemas de caché (a veces en forma de módulos) que no están activados por defecto pero que, una vez activados, permiten un aumento drástico del rendimiento.
Este tipo de caché suele estar desactivado por defecto, ya que cuando se modifica un tema (o plantilla), por ejemplo, puede que no se "recalcule" inmediatamente y, por tanto, no se muestren directamente las modificaciones realizadas, por lo que se recomienda que cuando se configure, codifique o modifique el tema de un sitio, se desactive la caché (o se fuerce su recreación siempre que sea posible después de realizar las modificaciones).
Este tipo de optimización es probablemente uno de los más interesantes en cuanto a los tiempos de carga del sitio, ya que el navegador del cliente sólo puede empezar a descargar los archivos del sitio una vez que ha empezado a recibir la página, que en su código HTML contiene las rutas de los demás archivos que hay que recuperar, y como PHP sólo devuelve la página al servidor Apache una vez que se ha "generado" completamente, si éste tarda más en generarse, el sitio tardará aún más en cargarse.
Caché PHP del lado del servidor (sólo para VDS y Dedicado)
La caché de código máquina, también conocida como caché de opcode, almacena en memoria el código PHP precalculado en código máquina y ahorra tiempo de cálculo y, por tanto, de carga.
Este tipo de caché tiene la ventaja de no requerir ninguna adaptación/configuración específica del script PHP que se está ejecutando, cualquier script PHP es compatible y no supone un problema con el contenido dinámico. Para utilizar este tipo de caché, PHP debe cargar un módulo adaptado, los tres más comunes actualmente son eAccelerator, APC y xCache; eAccelerator tiende a no ser utilizado más porque es menos mantenido que los dos últimos y generalmente menos eficiente, APC es casi tan eficiente como xCache pero tiene algunas características menos (un panel de administración que permite seguir el uso de la caché y comprobar el contenido está disponible bajo xCache por ejemplo) pero por otro lado está disponible por un período de tiempo más largo0 en particular, mientras que xCache sólo ha estado disponible como paquete precompilado desde Debian 5.0). Por lo tanto, es posible instalarlos escribiendo :
apt-get install php5-xcache
O :
apt-get install php-apc
(sólo se puede utilizar uno de estos módulos a la vez)
A continuación, puede adaptar la configuración a sus necesidades (tamaño de la caché, número máximo de entradas o habilitar la caché variable para xcache, por ejemplo)
Lista de opciones de configuración de xCache
Lista de opciones de configuración para APC
Compresión de los datos transmitidos por el servidor Apache (sólo VDS, Dedicado, Permium)
El módulo deflate de Apache permite comprimir "sobre la marcha" ciertos archivos como html, Javascript o CSS. Este módulo, activado por defecto en el alojamiento compartido, reduce la cantidad de datos que debe cargar el visitante del sitio.
En la instalación por defecto de Apache, el módulo deflate está instalado pero no necesariamente activo y su configuración por defecto sólo comprime los archivos html, también es posible utilizarlo para los archivos CSS y Javascript (que pueden tener un tamaño de varios cientos de kilobytes dependiendo del sitio), la tasa media de compresión está entre 50 y 75% en este tipo de archivos, lo que no es despreciable.
Puede ver el tamaño que tendrían los archivos con el módulo activado utilizando el módulo Pagespeed para Firefox (o su versión para Google Chrome), al ir a la pestaña "Pagespeed" y luego hacer clic en "Analizar el rendimiento" en la sección "Activar la compresión" y obtener un mensaje como :
La compresión de los siguientes recursos con gzip podría reducir su tamaño de transferencia en 100,1KiB (reducción de 72%).
Esto significa, en este caso, que la página podría reducirse de unos 150kb a 50kb con la compresión activada.
Para activar el módulo, basta con escribir el comando :
a2enmod deflate
Para habilitar la compresión de archivos que no son html, el archivo /etc/apache2/mods-available/deflate.conf debe modificarse tal cual:
<Si el módulo mod_deflate.c
# se sabe que son seguros con MSIE 6
AddOutputFilterByType DEFLATE text/html text/plain text/xml
# todo lo demás puede causar problemas con MSIE 6
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/x-javascript application/javascript application/ecmascript
AddOutputFilterByType DEFLATE application/rss+xml
BrowserMatch ^Mozilla/4.[0678] no-gzip
BrowserMatch bMSIEs(7|8|9) !no-gzip !gzip-only-text/html
(las dos últimas líneas deshabilitan la compresión de los archivos no html en ie6 e inferiores, lo que puede causar problemas al mostrar a veces páginas en blanco)
Entonces tienes que reiniciar Apache escribiendo este comando:
/etc/init.d/apache2 restart
Ahora, en "Pagespeed", debería tener una marca verde junto a "Compression Enabled" si está probando un sitio alojado en la máquina.
Español 
Français 
English