Applications multisites. Partage de ressources pour plusieurs domaines

Bonjour à tous.

Je bosse actuellement sur une appli sous Zend, qui a pour but de faire tourner plusieurs sites (en fait plusieurs sous-domaines) alimenté par une seule BDD.

Pour ceux qui connaissent un peu, l'idée que l'on a eu a été de mettre en place un module par sous-domaine, avec une redirection dans le bootstrap et une bidouille dans la définition des virtual hosts. L'article qui m'a guidé sur la mise en place (en anglais) : Routing Subdomains to Modules in Zend Framework.

Jusque là, tout roule, le but de partager les ressources communes niveau serveur (principalement les modèles, les plugins et les viewHelpers) est atteint.

Là ou je commence à m'interroger, c'est par rapport à tous ce qui est "ressources front-end".
Un exemple:

<img src="http://domain1.monsite/img/logo.jpg" / >
<img src="http://domain2.monsite/img/logo.jpg" / >

Deux urls, une même image. Dans le mesure ou il y a des liens entre les différents sites, ça me plait moyen niveau mise en cache.

La chose se reproduit également pour les css et les js partagés.

La première idée qui m'est venue est alors de créer un module vide, qui servent juste pour avoir un sous-domaine de "dépot", mais ça me pose plusieurs soucis.

- Obligation d'utiliser des urls absolues sur toute les images. Sur des pages avec beaucoup de pictos ou de visuels, je ne sais pas si le sur-poids sur le html ne va pas être conséquent.

- Pour les images, je me demande l'incidence au niveau référencement. Je pense en particulier à Google image comme possible point d'entrée au site.

- Pour les css, j'ai réglé le problème avec une css générale de layout + une par site. Pas parfait parce que ça m'oblige à rajouter pas mal de surcharge, et que pour ne pas rajouter 2 ou 3 feuilles pour les IE, je sais que mes css spécifiques à chaque site ne valident pas. Comme elle ne font même pas 50 lignes, ce n'est pas encore trop grave, mais si elles viennent à grossir, la facilité de maintenance va en prendre un coup.

- Au niveau du js, beaucoup de "widgets" se retrouvent d'un site à l'autre. Mais ça m'ennuie d'avoir un seule gros init qui va chercher des sélecteurs qui n'existent pas. Je pense que je recréerais un topic dans la section js juste pour ça car cette histoire est un beau morceau à elle toute seule.


Je me demandais, au vu des contraintes, quels serait votre approche pour :

- Si possible, garder des urls relatives, pour ne pas avoir un code html qui contiennent 50% d'attributs src.

- Faciliter au mieux la maintenance, en évitant le maximum les redondances d'un site à l'autre (le but étant que les mises à jours soient répercutées sur tous les sous-domaines).

- Éviter d'avoir plusieurs urls pour une même ressources, pour une mise en cache qui reste cohérente.

- Éviter d'éventuel effet de bords inattendus du point de vue référencement. Je pense pas qu'il y ait risque de Duplicate-content ou autre, mais dans le doute.

- Éventuellement, optimiser le tout, si vous avez des idées, n'hésitez pas.


Si vous avez des exemples de gros sites fonctionnant de le même manière, je suis bien entendu preneur.

Merci d'avance à pour vos lumières.


Note aux modos : Par commodité, j'ai regroupé plusieurs questions dans le même topic. Je le scinderais en plusieurs si nécessaire.

Hello !

C'est une complexe et épineuse question(s)

Je me suis posé à peu près les mêmes il y a quelques temps sur un projet nécessitant également la mutualisation de ressources cross-domaine. La solution qu'on avait alors retenu avait été de placer sur le serveur une "librairie" contenant nos ressources (modèles, contrôleurs, etc) dans un répertoire spécifique sur le serveur (/var/lib) et de faire pointer les includes path du bootstrap vers cet espace (on utilise un framework maison, mais ça doit être possible avec Zend). Si les domaines sont hébergés sur différentes machines, on a également prévu un partage NFS de la librairie pour qu'elle soit toujours à jour, partout.

Pour les ressources accessibles (images et js), la seule solution qui nous semblait convenable était d'utiliser un sous-domaine dédié, sur une machine dédiée tournant avec nginx. Il a l'incontestable avantage d'etre très réactif sur la diffusion de ressources statiques. Certes, ca produit des attributs SRC à rallonge, mais on peut utiliser un domaine court spécifique (zzz.me par exemple) pour limiter la longueur des urls. A priori, il ne me semble pas que ça perturbe le referencement, notamment sur Google image, mais si quelqu'un a plus d'infos là dessus, je suis preneur !

Voilà, c'était mes deux centimes ...

Salut...

Bon Les serveurs c'est pas trop mon truc, bien que j'ai compris ce qu'avait fait MAD's...

Toutefois.... par expérience d'où j'ai bossé et par expérience du net je dirai :

Partager des ressources depuis un autre serveur et un autre domaine que celui concerné directement ne pose normalement pas de problèmes, ni au niveau du référencement, ni au niveau du fonctionnement.

Nombre sont les librairie JS qui sont hébergées à droite ou à gauche et utilisée par tout le monde.
Exemple concret avec Jquery hébergé par GOOGLE et appelable par tout le monde. Ca marche aussi bien pour des ressources images.

Se pose plus la question de savoir si toutes ces ressources partagées vont être sur un serveur :
- Toujours disponible ?
- Suffisamment puissant pour répondre aux multiples requêtes ?
- Sécurisé quant au domaine qui y accéderont pour afin que les librairies ne soit pas "voler" par d'autres indésirables (cette dernières question dépendant des ressources que tu partagera).


Pour le reste pas de soucis de référencement, mais pour la redondance, le bot de google faisant des indexations au nombre de lien pointant vers quelque chose, il y a le risque que le domaine possédant les ressources soit toujours devant le domaine esclave qui appelle la ressource.


Voilà c'était ma goutte d'eau

Déjà, merci @MAD's et @pchlj pour les retours.

Maintenant, je viens de relire mon propre post et me rends compte qu'il est quand même assez imbitable (manque de sommeil certainement).

Donc, en très résumé, comment vous y prenez vous pour partager vous plusieurs ressources entre plusieurs domaines?

Préférez vous créer un sous-domaine pour héberger le tout, ou vous avez d'autres astuces?

Encore merci d'avance.

Pour des raisons évidentes de sécurité moi je placerais l'ensemble des ressources partagées dans un sous domaine de ton domaine principal...

Ca prend peu de place, et il n'y aura là que les ressources.

C'est simple à gérer et à mettre à jour en ftp. voir en cvs ou même par des cron du domaine principal si il y a de gros changements.. enfin bref c'est un lieu accessible par l'ensemble du domaine principal et par tout autre domaine qui pointe dessus en adresse absolue.

Je vais te faire une réponse qui n'en est pas vraiment une : ça dépend

Si les ressources accessibles (j'entends par là des js / img / etc) doivent êtres partagées entre plusieurs domaines différents (par exemple xxx.com et yyy.com), alors j'aurais tendance à passer par un domaine dédié (par exemple zzz.com) pour partager les ressources. Ca aura le double avantage de n'avoir qu'un seul dépôt à mettre à jour, et les données seront disponibles en cache navigateur si l'utilisateur vient à naviguer sur les différents domaines (c'est ce qu'on fait en chargeant jquery depuis Google code d'ailleurs)

Si les ressources sont partagées entre plusieurs sous-domaines d'un même domaine principal, alors un sous-domaine dédié fera l'affaire (resources.xxx.com). Ca économisera un nom de domaine supplémentaire (à 12 euros par an )

Au final on se rejoint ... Après, on peut envisager des infrastructures multi-serveur pour répartir la charge entre les machines, et sur des serveurs http optimisés par la distribution de ressources statiques (un p'tit coup de nginx ?). Mais c'est peut-être une autre histoire ...

On pourrait aussi imaginer mettre en place un sous-domaine de notre domaine principal (dans mon cas : sources.madsgraphics.com par exemple), qui hébergerait nos sources, distribuées entre tous les sites de nos clients / réalisations, et qui serait mis à jour automatiquement via un hook à chaque push sur le dépôt git central (quoi, je délire ?) ...

J'ai encore plein d'idées rigolotes comme ça dans mon chapeau ...

J'espère avoir été utile