En AskApache han publicado una entrada titulada Optimize a Website
for Speed, Security, and Easy
Management
que recomiendo leer.
Como bien indican y siempre argumento, tener un sitio web con los
ficheros metidos en cualquier sitio, imágenes mezcladas con ficheros de
código, varias plantillas (index.html, index1.html, index-old.html ¿os
suena?), etcétera, a la larga lo único que trae es inconsistencias y
dolor de cabeza a la hora de meter mano.
Para empezar la entrada propone la siguiente estructura:
/home/askapache.com |-- /home/askapache.com/backups/ |-- /home/askapache.com/htdocs/ |-- /home/askapache.com/inc/ |-- /home/askapache.com/logs/ |-- /home/askapache.com/static/ |-- /home/askapache.com/tmp/ |-- /home/askapache.com/.htpasswd-basic |-- /home/askapache.com/.htpasswd-digest
Es decir, en el $HOME (sí: se asume servidores Unix-like. Como la
mayoría de servidores serios) un directorio por cada dominio y dentro
una estructura fácil de mantener:
- /backups/. Donde guardaremos las copias de seguridad del sitio.
- /htdocs/. La raíz del sitio web.
- /inc/. Para esos ficheros PHP (y otros lenguajes) que se van a
incluir (por ejemplo con
include()orequiere()) aparte del sistema o CMS usado para la web.
- /logs/. Donde guadaremos los registros de errores del PHP, de
visitas/errores del Apache o al menos será un enlace simbólico apuntando
a la ruta donde se almacenarán.
- /static/. La raíz donde guardar los ficheros estáticos.
- /tmp/. Sólo necesario si el hosting no dispone de un directorio
/tmp en la raíz del sistema de ficheros (o éste no es accesible para el
usuario que administra los ficheros de la web).
El artículo se desarrolla mucho más (optimizaciones, reducción de
cabeceras HTTP 403, consejos, sistemas de cache y muchos enlaces) pero
sólo para empezar ya es un gran consejo.
Sobretodo el uso del static (el cual puede ser un subdominio tipo
http://static.tusitio.com o un subdirectorio), el ejemplo que da sirve
para imaginar cómo ordenarlo:
/home/askapache.com/static/ | |-- /home/askapache.com/static/css/ | |-- /home/askapache.com/static/flv/ | |-- /home/askapache.com/static/img/ | |-- /home/askapache.com/static/js/ | |-- /home/askapache.com/static/mp3/ | |-- /home/askapache.com/static/pdf/ | |-- /home/askapache.com/static/swf/ | |-- /home/askapache.com/static/.htaccess | |-- /home/askapache.com/static/index.html | |-- /home/askapache.com/static/robots.txt
Y si bien en casa de herrero, cuchara de madera (a mí me hubiera
gustado seguir algo así, pero por no liarme mucho en su día con
WordPress, su /wp-content/uploads y sobretodo para no dar muchos
dolores de cabeza a los colaboradores no lo hice) las posibilidades de
tener separado contenido de presentación y "media" en general permite
muchas posibilidades que de otra manera requerirían código extra y/o
crearían posibles conflictos:
- Administrar de diferente forma el hotlinking a imágenes y el acceso
a otros ficheros.
- Capar bots que nos interesa que accedan de diferente forma a cada
tipo de contenido.
- Organizar los contenidos.
- Programar backups más eficientes (en mi caso, de los directorios
listados, los cuatro últimos no cambiarían prácticamente nunca).
Por no hablar de aumentar la capacidad de servir contenidos separando static en un servidor distinto de la web en sí o de la base de datos...
Comentarios