Fichero .htaccess para bitácoras con CMS WordPress

A cuenta de la anotación de Armonth sobre la optimización de su bitácora SigT, tal vez os sea útil (o alguien pueda complementarlo/mejorarlo).

UTI (portada) desde Firebug (todo)

.htaccess de unatemporadaenelinfierno.net

<Limit GET POST>
order allow,deny
allow from all
</Limit>

<Limit PUT DELETE>
order deny,allow
deny from all
</Limit>

AuthName http://www.unatemporadaenelinfierno.net

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

<Files 403.shtml>
order allow,deny
allow from all
</Files>

# HEADERS and CACHING
# 1 YEAR
<FilesMatch “\.(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$”>
Header set Cache-Control “public”
Header set Expires “Mon, 11 Apr 2011 20:00:00 GMT”
Header unset Pragma
Header unset Last-Modified
Header unset ETag
FileETag None
</FilesMatch>

# 2 DAYS
<FilesMatch “\.(xml|txt)$”>
Header set Cache-Control “max-age=172800, public, must-revalidate”
Header unset Pragma
Header unset Last-Modified
Header unset ETag
FileETag None
</FilesMatch>

# 2 HOURS
<FilesMatch “\.(html|htm)$”>
Header set Cache-Control “max-age=7200, must-revalidate”
Header unset Pragma
Header unset ETag
FileETag None
</FilesMatch>

# COMPRESSION
<FilesMatch “\.(js|css)$”>
SetOutputFilter DEFLATE
</FilesMatch>

Anuncios

Acerca de maty
Nauscopio Scipiorum

8 Responses to Fichero .htaccess para bitácoras con CMS WordPress

  1. maty says:

    Por cierto, si miráis el código de la página portada de UTI, al final descubriréis que, a pesar de las numerosas funcionalidades incorporadas, el número de peticiones a la base de datos, el tiempo de carga/generación y el consumo de memoria son ridículos!!!

    19 queries. 0.337 seconds.
    Consumo de PHP: 10.48MB.

    Lo dicho, siempre hay que OPTIMIZAR.
    Nota: las imágenes/fotos están en Flickr desde siempre, con lo que la migración a otro servidor es más sencilla, aunque tal vez tarden un pelín más en cargarse que si estuviesen en el mismo servidor.

  2. maty says:

    Mangas Verdes 10 excelentes trucos .htaccess para WordPress y una recomendación 23.03.2009
    Investigaré sobre cómo mejorar la compresión de forma que se reduzca aún más el tráfico de un modo efectivo.

  3. maty says:

    Tras revisar la portada y las anotaciones de UTI gracias a la extensión Firebug para Firefox, no se me ocurre nada para mejorar la carga, como temía. Si a alguien se le ocurre algo que lo cuente!
    Imagen UTI-portada-firebug-todo.png
    Nota: fijaos cómo está todo optimizado. Lo que penaliza son las fotografías alojadas en Flickr.

  4. maty says:

    Una de las bitácoras que cuido fue suspendida temporalmente por exceso de consumo de recursos en un servidor web compartido canadiense (iWeb).

    >> For the following reasons :
    >> [X] Ressource Usage – Usage above the tolerated treshold

    http://es.iweb.com/acerca-de-nosotros/uso-aceptable/

    Uso de recursos
    iWeb Hébergement
    En alojamiento mutializado está prohibído, sin previo acuerdo de iWeb Technologies Inc., de permitir el acceso a los recursos de su (sus) cuenta(s) sobre un (des) servidor (s) de iWeb Technologies Inc. A usuarios de otros servidores externos. Sin ser limitado, esta prohibición se aplica a la utilización de su cuenta con el fin de que preste servicios públicos de contadores, de estadísticas o de otros servicios dinámicos destinados a ser utillizados por un gran número de sitios externos (scripts). En todo momento las cuentas de alojamiento mutualizado deben utilizar una parte aceptable de los recursos sistemas asignados al conjunto de los clientes que comparten la misma arquitectura. Cada cuenta usuario no debe utilizar más de un 2% de los recursos del sistema. Los scripts no deben en ningún caso interagir con el material del servidos o con su configuración.

    Estuve optimizándola -falta prescindir del uso de widgets e implementar vía código las funcionalidades del lateral. Probé diversos plugins para el cacheo hasta que encontré el que me parece mejor, el cual os recomiendo a quienes utilicéis el CMS WordPress 2.9.*
    -> WordPress.org W3 Total Cache
    Ahora mismo (seis horas de diferencia)
    05:00:03 AM CPU: 1.61% Memoria 1.19%
    El día 12 llegó a:
    03:30:08 PM CPU: 5.06% Memoria 4.39%

  5. maty says:

    En estos momentos.
    06:00:05 AM CPU 1.11% Memoria 1.71%
    Pues eso, debiérais dar una oportunidad al plugin W3 Total Cache.

  6. maty says:

    Sigt.net Cómo optimizar WordPress 3.0

    Desactiva las revisiones y el autosave…
    Aumenta el máximo de memoria usable…
    Los obvios: menos plugins y sistema de cache…
    Plantillas con menos llamadas: codifica a mano
    Limita el número de RSS que se muestran en el Dashboard…
    (Semi-avanzado) desactivar partes del código…
    Paso definitivo: Really Static…

    Llevo años insistiendo: los plugins conviene insertarlos manualmente y no vía widgets.

    Entre pitos y flautas sigo manteniendo WP 2.0.11 “nauscópico” en can Quiñonero [Una temporada en el infierno], esperando a una nueva versión WP 3.* que me convenza y que no sobrecargue más que mi versión optimizada/asegurada.

  7. maty says:

    Ayuda WordPress Usa .htaccess como Firewall

    El fichero .htaccess es la primera línea de entrada de cualquier sistema web montado sobre Apache, así que también puede convertirse en la primera línea de defensa frente a ataques de hackers, inyecciones de código o intrusiones…

"Age quod agis et bene agis" - Hagas lo que hagas, hazlo bien

Por favor, inicia sesión con uno de estos métodos para publicar tu comentario:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s