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