Un seul fichier .css énorme par rapport à plusieurs fichiers .css spécifiques plus petits? [fermé]


258

Y a-t-il un avantage à avoir un seul fichier monstre .css contenant des éléments de style qui seront utilisés sur presque toutes les pages?

Je pense que pour faciliter la gestion, j'aimerais retirer différents types de CSS dans quelques fichiers, et inclure chaque fichier dans mon fichier principal <link />est-ce mauvais?

Je pense que c'est mieux

  1. positions.css
  2. buttons.css
  3. tables.css
  4. copy.css

contre.

  1. site.css

Avez-vous vu des problèmes avec le faire d'une manière contre l'autre?


1
C'est vraiment une vieille question, mais face au même problème, j'ai trouvé celle que je pense que c'est la meilleure solution , au cas où quelqu'un d'autre arriverait sur cette page. Plusieurs fichiers compressés avec PHP et envoyés via une seule demande.
Francisco Presencia,

3
@FrankPresenciaFandos faire cela est correct pour un site à faible trafic, mais exécuter ce script encore et encore sur des sites à fort trafic semble un peu décalé. Si vous utilisez un script de construction, vous pouvez avoir le meilleur des deux mondes et toujours maintenir un serveur Web performant car il n'exécute pas le script php (jamais).
Chase Florell

2
Il serait exécuté uniquement à chaque fois que le CSS est modifié, puis vous devriez inclure le fichier CSS résultant.
Francisco Presencia

Réponses:


85

Un compilateur CSS comme Sass ou LESS est une excellente façon de procéder. De cette façon, vous serez en mesure de fournir un seul fichier CSS minimisé pour le site (qui sera beaucoup plus petit et plus rapide qu'un fichier source CSS normal), tout en conservant l'environnement de développement le plus agréable, avec tout parfaitement divisé en composants.

Sass et LESS ont l'avantage supplémentaire de variables, d'imbrication et d'autres façons de rendre CSS plus facile à écrire et à maintenir. Hautement recommandé. Personnellement, j'utilise maintenant Sass (syntaxe SCSS), mais j'ai utilisé MOINS auparavant. Les deux sont excellents, avec des avantages similaires. Une fois que vous avez écrit CSS avec un compilateur, il est peu probable que vous souhaitiez vous en passer.

http://lesscss.org

http://sass-lang.com

Si vous ne voulez pas jouer avec Ruby, ce compilateur MOINS pour Mac est génial:

http://incident57.com/less/

Ou vous pouvez utiliser CodeKit (par les mêmes gars):

http://incident57.com/codekit/

WinLess est une interface graphique Windows pour compiler MOINS

http://winless.org/


2
Changer ma réponse acceptée ici, car c'est vraiment la voie à suivre ces jours-ci. Quand j'ai demandé à l'origine, je n'ai pas l'impression que Sass ou LESS avait vraiment décollé.
Nate

144

C'est difficile à répondre. Les deux options ont à mon avis leurs avantages et leurs inconvénients.

Personnellement, je n'aime pas lire un seul fichier CSS ÉNORME, et le maintenir est très difficile. D'un autre côté, le fractionnement entraîne des demandes http supplémentaires qui pourraient potentiellement ralentir les choses.

Mon opinion serait l'une des deux choses.

1) Si vous savez que votre CSS ne changera JAMAIS une fois que vous l'avez construit, je construirais plusieurs fichiers CSS au stade du développement (pour plus de lisibilité), puis les combiner manuellement avant de passer en direct (pour réduire les demandes http)

2) Si vous savez que vous allez changer votre CSS de temps en temps et que vous devez le garder lisible, je construirais des fichiers séparés et utiliserais du code (à condition d'utiliser une sorte de langage de programmation) pour les combiner à temps de construction du runtime (la minification / combinaison du runtime est un pig de ressource).

Avec l'une ou l'autre option, je recommande fortement la mise en cache côté client afin de réduire davantage les requêtes http.

EDIT:
J'ai trouvé ce blog qui montre comment combiner CSS à l'exécution en utilisant uniquement du code. Cela vaut la peine d'y jeter un coup d'œil (même si je ne l'ai pas encore testé moi-même).

EDIT 2:
J'ai décidé d'utiliser des fichiers séparés dans mon temps de conception et un processus de construction pour réduire et combiner. De cette façon, je peux avoir des CSS séparés (gérables) pendant que je développe et un bon fichier minifié monolithique au moment de l'exécution. Et j'ai toujours mes fichiers statiques et moins de surcharge système car je ne fais pas de compression / minification au moment de l'exécution.

Remarque: pour vous, acheteurs, je suggère fortement d'utiliser le bundler dans le cadre de votre processus de construction. Que vous construisiez à partir de votre IDE, ou à partir d'un script de construction, le bundler peut être exécuté sur Windows via le inclus exeou peut être exécuté sur n'importe quelle machine qui exécute déjà node.js.


Outre le nombre réduit de requêtes HTTP, le fichier monolithique unique présente-t-il un avantage? Mon CSS peut changer au fil du temps, mais le nombre d'utilisateurs sera assez petit, la plupart y accédant via des connexions à haut débit. Je pense donc que l'avantage de plusieurs fichiers sera bien supérieur à moins de requêtes http ...
Nate

1
moins de requêtes HTTP EST la raison. retenir les visiteurs est la priorité n ° 1, donc si votre page se charge lentement, ils sont moins susceptibles de rester. Si vous avez la possibilité de combiner (je vois que vous utilisez asp.net), je vous recommande fortement de le faire. C'est le meilleur des deux mondes.
Chase Florell

3
"Je pense donc que l'avantage de plusieurs fichiers sera bien plus grand que moins de requêtes http ..." Non, non, non ... exactement le contraire. Avec une connexion haut débit, le temps nécessaire pour traiter les requêtes HTTP est le goulot d'étranglement. La plupart des navigateurs par défaut ne téléchargent que deux fichiers à la fois, donc les navigateurs feraient 2 demandes, attendraient, téléchargeraient rapidement les fichiers css, enverraient 2 demandes supplémentaires, attendraient, téléchargeraient rapidement les fichiers. Contrairement à une demande HTTP pour un fichier CSS, il se télécharge rapidement. La communication avec le serveur serait la partie lente.
Isley Aardvark

1
Vous pouvez créer et tester des fonctionnalités avec des feuilles de style distinctes et les combiner en une seule mongo par génération. De cette façon, vous ne conservez pas un seul fichier mongo mais de nombreux fichiers plus petits. Nous faisons cela ainsi que compressons tous les espaces et commentaires qui facilitent la lecture par les humains mais qui n'ont aucun sens pour vos pages Web.
Aucun remboursement Aucun retour

2
Ce serait d'avoir cette réponse mise à jour maintenant que http2 réduit l'avantage de moins de requêtes.
DD.

33

Je préfère plusieurs fichiers CSS pendant le développement. La gestion et le débogage sont beaucoup plus faciles de cette façon. Cependant, je suggère qu'au moment du déploiement, vous utilisez à la place un outil de réduction CSS comme YUI Compressor qui fusionnera vos fichiers CSS en un seul fichier monolithique.


@Randy Simon - mais que se passe-t-il si nous modifions css directement sur ftp toujours.
Jitendra Vyas

15
Je ne connais pas votre configuration, mais cela ne me semble pas être une bonne idée. Vous devez tester les modifications avant de les supprimer.
Randy Simon

1
@RandySimon le lien du compresseur YUI est rompu.
reformé le

16

Vous voulez les deux mondes.

Vous voulez plusieurs fichiers CSS parce que votre santé mentale est une chose terrible à perdre.

Dans le même temps, il est préférable d'avoir un seul fichier volumineux.

La solution est d'avoir un mécanisme qui combine les fichiers multiples en un seul fichier.

Un exemple est quelque chose comme

<link rel="stylesheet" type="text/css" href="allcss.php?files=positions.css,buttons.css,copy.css" />

Ensuite, le script allcss.php gère la concaténation des fichiers et leur remise.

Idéalement, le script vérifierait les dates de modification sur tous les fichiers, créerait un nouveau composite si l'un d'entre eux change, puis renvoie ce composite, puis vérifie les en-têtes HTTP If-Modified afin de ne pas envoyer de CSS redondant.

Cela vous donne le meilleur des deux mondes. Fonctionne également très bien pour JS.


7
cependant, la compression / minification à l'exécution a une surcharge système. Vous devez peser le pour et le contre. Si vous avez un site à fort trafic, ce n'est pas une solution optimale.
Chase Florell

5
@ChaseFlorell - il vous suffit de faire la compression / minification une fois et de la mettre en cache
Siler

@Siler, je sais, c'est pourquoi j'ai posté ma réponse. stackoverflow.com/a/2336332/124069
Chase Florell

14

Avoir un seul fichier CSS est meilleur pour le temps de chargement de vos pages, car cela signifie moins de requêtes HTTP.

Avoir plusieurs petits fichiers CSS signifie que le développement est plus facile (du moins, je pense que oui: avoir un fichier CSS par module de votre application facilite les choses) .

Donc, il y a de bonnes raisons dans les deux cas ...


Une solution qui vous permettrait de tirer le meilleur parti des deux idées serait:

  • Pour développer en utilisant plusieurs petits fichiers CSS
    • c'est-à-dire plus facile à développer
  • Pour avoir un processus de construction pour votre application, qui "combine" ces fichiers en un seul
    • Ce processus de construction pourrait également réduire ce gros fichier, btw
    • Cela signifie évidemment que votre application doit avoir des éléments de configuration qui lui permettent de passer du "mode multi-fichiers" au "mode mono-fichier".
  • Et pour utiliser, en production, uniquement le gros fichier
    • c'est-à-dire un chargement plus rapide des pages

Il existe également des logiciels qui combinent les fichiers CSS au moment de l'exécution et non au moment de la construction; mais le faire au moment de l'exécution signifie manger un peu plus de CPU (et nécessite évidemment un certain mécanisme de mise en cache, pour ne pas recréer trop souvent le gros fichier)


14

Historiquement, l'un des principaux avantages x d'avoir un seul fichier CSS est l'avantage de la vitesse lors de l'utilisation de HTTP1.1.

Cependant, en mars 2018, plus de 80% des navigateurs prennent désormais en charge HTTP2, ce qui permet au navigateur de télécharger plusieurs ressources simultanément et de pouvoir pousser les ressources de manière préventive. Avoir un seul fichier CSS pour toutes les pages signifie une taille de fichier plus grande que nécessaire. Avec une conception appropriée, je ne vois aucun avantage à le faire autre que sa plus facile à coder.

La conception idéale pour HTTP2 pour de meilleures performances serait:

  • Avoir un fichier CSS de base qui contient des styles communs utilisés sur toutes les pages.
  • Avoir un CSS spécifique à la page dans un fichier séparé
  • Utilisez HTTP2 push CSS pour minimiser le temps d'attente (un cookie peut être utilisé pour éviter les poussées répétées)
  • Séparez éventuellement au-dessus du CSS et pliez-le d'abord et chargez le CSS restant plus tard (utile pour les appareils mobiles à faible bande passante)
  • Vous pouvez également charger le CSS restant pour le site ou des pages spécifiques après le chargement de la page si vous souhaitez accélérer les futurs chargements de page.

1
Ce devrait être la réponse RE moderne acceptée. Certaines autres réponses sont obsolètes.
SparrwHawk

Si vous construisez un SPA (application d'une seule page), je dirais que la meilleure conception est de construire tous vos CSS et JS dans deux fichiers complets. "app.js" et "vendor.js" Tout le code HTML et les styles sont compilés pour JS en ligne dans vendor.js Cela signifie que "bootstrap.css et bootstrap.js" sont tous dans vendor.js et il est minimisé avec des sourcemaps dans " vendor.min.js ". Même chose avec l'application, sauf que maintenant vous utilisez un transpilateur en ligne html vers js donc même le HTML de vos applications est dans le fichier js. Vous pouvez les héberger sur un CDN et les navigateurs les mettront en cache. Vous pouvez même compiler des images dans des styles et dans JS.
Ryan Mann

12

Les feuilles de style monolithiques offrent de nombreux avantages (qui sont décrits dans les autres réponses), mais en fonction de la taille globale du document de feuille de style, vous pouvez rencontrer des problèmes dans IE. IE a une limitation avec le nombre de sélecteurs qu'il lira à partir d'un seul fichier . La limite est de 4096 sélecteurs. Si vous êtes feuille de style monolithique aura plus que cela, vous voudrez le diviser. Cette limitation ne fait que montrer sa tête laide dans IE.

C'est pour toutes les versions d'IE.

Voir le blog de Ross Bruniges et la page MSDN AddRule .


7

Il y a un point de basculement auquel il est avantageux d'avoir plus d'un fichier CSS.

Un site avec 1M + de pages, dont l'utilisateur moyen ne verra probablement que 5, pourrait avoir une feuille de style aux proportions immenses, donc essayer d'économiser la surcharge d'une seule demande supplémentaire par chargement de page en ayant un téléchargement initial massif est faux économie.

Étirez l'argument à l'extrême limite - c'est comme suggérer qu'il devrait y avoir une grande feuille de style maintenue pour l'ensemble du Web. Clairement absurde.

Le point de basculement sera différent pour chaque site, il n'y a donc pas de règle stricte et rapide. Cela dépendra de la quantité de CSS uniques par page, du nombre de pages et du nombre de pages que l'utilisateur moyen est susceptible de rencontrer régulièrement lors de l'utilisation du site.


Oui. C'est la question sur laquelle je suis venu ici. Tout le monde se concentre sur le développement contre la production. Bien sûr, votre environnement de développement peut être différent de votre site en ligne, mais quel est le meilleur pour le site en ligne? Personne ne semble vraiment aborder cette question. Connaissez-vous des ressources pour trouver le point de basculement?
Dominic P

5

J'ai généralement une poignée de fichiers CSS:

  • un fichier css "global" pour les réinitialisations et les styles globaux
  • "css" des fichiers css spécifiques pour les pages qui sont regroupées logiquement (peut-être chaque page dans un assistant de paiement ou quelque chose)
  • "css" des fichiers css spécifiques pour les remplacements sur la page (ou, mettez cela dans un bloc sur la page individuelle)

Je ne suis pas vraiment trop préoccupé par les demandes de plusieurs pages pour les fichiers CSS. La plupart des gens ont une bande passante décente et je suis sûr qu'il existe d'autres optimisations qui auraient un impact beaucoup plus important que la combinaison de tous les styles dans un fichier CSS monolitique. Le compromis est entre la vitesse et la maintenabilité, et je penche toujours vers la maintenabilité. Le compresseur YUI semble plutôt cool, je devrais peut-être vérifier cela.


C'est ce que je fais et ça marche bien pour moi. Au plus, vous obtenez 3 fichiers css pour chaque page, ce qui est assez raisonnable
Ricardo Nunes

4

Je préfère plusieurs fichiers CSS. De cette façon, il est plus facile d'échanger des "skins" à l'intérieur et à l'extérieur comme vous le souhaitez. Le problème avec un fichier monolithique est qu'il peut devenir incontrôlable et difficile à gérer. Que faire si vous voulez des arrière-plans bleus mais ne voulez pas que les boutons changent? Modifiez simplement votre fichier d'arrière-plan. Etc.


le problème est que c'est assez égoïste du point de vue des développeurs. Une fois que vous avez terminé, vous devez rarement y retourner, mais vos visiteurs doivent tous attendre que les pages chargent des fichiers CSS inutiles. (Il en va de même pour Javascript à mon avis)
Chase Florell

3
@rockin: En vérifiant l'un de mes sites de fichiers 5 CSS après avoir effacé mon cache, j'ai découvert que le temps total nécessaire pour charger tous les CSS était inférieur à un dixième de seconde. Si les gens ne peuvent pas attendre aussi longtemps, je pense qu'ils ont besoin de plus de Ritalin ou quelque chose. Ce qui est un problème beaucoup plus important, ce sont les rappels vers des sites d'annonces comme doubleclick, etc., qui peuvent entraîner d'énormes retards, comme en témoigne ce site au cours de la semaine dernière.
Robusto

Un excellent outil à utiliser pour tester les vitesses du site est Firebug en conjonction avec YSlow. Cela devrait vous donner une représentation précise des vitesses de votre site.
Chase Florell

4

Jetez peut-être un œil à la boussole , qui est un cadre de création CSS open source. Il est basé sur Sass , il prend donc en charge des choses intéressantes comme les variables, l'imbrication, les mixins et les importations. Les importations sont particulièrement utiles si vous souhaitez conserver des fichiers CSS plus petits mais les combiner automatiquement en 1 (en évitant plusieurs appels HTTP lents). Compass ajoute à cela un grand ensemble de mixins prédéfinis qui sont faciles à gérer des trucs multi-navigateurs. Il est écrit en Ruby mais il peut facilement être utilisé avec n'importe quel système ....


3

voici le meilleur moyen:

  1. créer un fichier css général avec tout le code partagé
  2. insérer tout le code CSS de page spécifique dans la même page, sur la balise ou en utilisant l'attribut style = "" pour chaque page

de cette façon, vous n'avez qu'un seul css avec tout le code partagé et une page html. au fait (et je sais que ce n'est pas le bon sujet) vous pouvez également encoder vos images en base64 (mais vous pouvez aussi le faire avec vos fichiers js et css). de cette façon, vous réduisez encore plus de requêtes http à 1.


2

SASS et LESS font de tout cela un point discutable. Le développeur peut configurer des fichiers de composants efficaces et les compiler lors de la compilation. Dans SASS, vous pouvez désactiver le mode compressé pendant le développement pour une lecture plus facile et le réactiver pour la production.

http://sass-lang.com http://lesscss.org

En fin de compte, un seul fichier CSS minifié est ce que vous voulez, quelle que soit la technique que vous utilisez. Moins de CSS, moins de requêtes HTTP, moins de demande sur le serveur.


1

L'avantage d'un fichier CSS unique est l'efficacité du transfert. Chaque demande HTTP signifie une réponse d'en-tête HTTP pour chaque fichier demandé, et cela prend de la bande passante.

Je sers mon CSS en tant que fichier PHP avec le type MIME "text / css" dans l'en-tête HTTP. De cette façon, je peux avoir plusieurs fichiers CSS côté serveur et utiliser PHP inclut pour les pousser dans un seul fichier à la demande de l'utilisateur. Chaque navigateur moderne reçoit le fichier .php avec le code CSS et le traite comme un fichier .css.


Donc, si j'utilise ASP.NET, un gestionnaire générique .ASHX serait l'itinéraire idéal, qui les combine en un seul fichier pour tirer le meilleur parti des deux mondes?
Nate

Oui, j'utiliserais un IHttpHandler pour combiner votre CSS lors de l'exécution (voir # 2 dans ma réponse ci-dessus)
Chase Florell

@Nate: Lorsque je travaillais dans ASP.Net, nous avons utilisé des fichiers de modèle pour accomplir la même chose.
Robusto

@Robusto, pourriez-vous expliquer ce qu'est un fichier modèle? Je ne pense pas en avoir jamais entendu parler. J'ai utilisé App_Themes, mais cela ne combine toujours pas CSS.
Chase Florell

1
juste comme une mise à jour. L'utilisation d'un IHttpHandler ou d'un fichier PHP pour combiner css côté serveur peut économiser de la bande passante et accélérer les demandes, mais cela ajoute également une charge inutile sur le serveur. La meilleure façon de le faire est de combiner / réduire votre css / js lors de la construction / publication de votre site. De cette façon, vous avez un seul fichier statique qui ne prend aucun traitement serveur. Le meilleur de TOUS les mondes, sauf AUCUN.
Chase Florell

1

Vous pouvez simplement utiliser un fichier css pour les performances, puis commenter des sections comme celle-ci:

/******** Header ************/
//some css here

/******* End Header *********/


/******** Footer ************/
//some css here

/******* End Footer *********/

etc


4
Cela ne facilite pas la maintenance, car j'ai encore besoin de parcourir des kilomètres de CSS non liés pour arriver à ce que je recherche ...
Nate

2
@Nate: Avez-vous envisagé de passer à un éditeur de texte avec une fonctionnalité de recherche décente? Ma préférence personnelle est un seul fichier CSS et je ne le fais jamais défiler. Je tape simplement "/ classname" (j'utilise un dérivé vi) et bam - je suis dans cette classe.
Dave Sherohman

3
Il est également plus difficile à maintenir dans un environnement multi-développeurs. Qu'est-ce qu'un "en-tête" dans votre exemple ci-dessus? Et si quelqu'un d'autre ne pense pas géographiquement, mais en termes d'éléments de conception de base, comme les boutons ou les menus, alors que d'autres pensent différemment? Où va un menu s'il est dans un en-tête? Et si ce n'était pas le cas? Je pense qu'il est plus facile d'appliquer ce type de discipline dans des fichiers séparés. Pourquoi les développeurs d'applications ne créent-ils pas simplement une énorme classe d'application avec tous les ajustements au lieu d'un cadre avec une hiérarchie de classes? Semble semblable à moi.
Robusto

Et si vous ne vous souvenez pas du nom du cours que vous recherchez? Ou comment décidez-vous où ajouter une nouvelle classe?
Nate

Si ce n'est qu'un site Web de quelques pages, ce n'est vraiment pas si grave. Je suggère simplement une autre façon de faire les choses.
Catfish

1

J'utilise Jammit pour gérer mes fichiers CSS et utiliser de nombreux fichiers différents pour plus de lisibilité. Jammit effectue tout le sale travail de combinaison et de compression des fichiers avant le déploiement en production. De cette façon, j'ai de nombreux fichiers en développement mais un seul fichier en production.


0

Une feuille de style intégrée peut enregistrer les performances de chargement de la page, mais plus il y a de styles, plus le navigateur rend les animations lentes sur la page sur laquelle vous vous trouvez. Cela est dû à l'énorme quantité de styles inutilisés qui peuvent ne pas être sur la page sur laquelle vous vous trouvez, mais le navigateur doit encore calculer.

Voir: https://benfrain.com/css-performance-revisited-selectors-bloat-expensive-styles/

Avantages des feuilles de style fournies: - performances de chargement des pages

Inconvénients des feuilles de style groupées: - comportement plus lent, ce qui peut provoquer des saccades pendant le défilement, l'interactivité, l'animation,

Conclusion: Pour résoudre les deux problèmes, pour la production, la solution idéale est de regrouper tous les css dans un fichier pour enregistrer sur les requêtes http, mais utilisez javascript pour extraire de ce fichier, le css de la page sur laquelle vous vous trouvez et mettre à jour la tête avec .

Pour savoir quels composants partagés sont nécessaires par page et pour réduire la complexité, il serait bien d'avoir déclaré tous les composants que cette page particulière utilise - par exemple:

<style href="global.css" rel="stylesheet"/>
<body data-shared-css-components="x,y,z">

-1

J'ai créé une approche systématique du développement CSS. De cette façon, je peux utiliser une norme qui ne change jamais. J'ai d'abord commencé avec le système de grille 960. Ensuite, j'ai créé des lignes simples de CSS pour les mises en page de base, les marges, le rembourrage, les polices et les tailles. Je les enchaîne ensuite au besoin. Cela me permet de conserver une mise en page cohérente dans tous mes projets et d'utiliser les mêmes fichiers CSS à plusieurs reprises. Parce qu'ils ne sont pas spécifiques. Voici un exemple: ---- div class = "c12 bg0 m10 p5 white fl" / div --- Cela signifie que le conteneur est de 12 colonnes, utilise bg0 a des marges de 10px de 5, le texte est blanc et il flotte la gauche. Je pourrais facilement changer cela en supprimant ou en ajoutant un nouveau - ce que j'appelle un style "léger" - au lieu de créer une seule classe avec tous ces attributs; Je combine simplement les styles uniques en codant la page. Cela me permet de créer n'importe quelle combinaison de styles et ne limite pas ma créativité ni ne me fait créer un grand nombre de styles similaires. Vos feuilles de style deviennent beaucoup plus gérables, minimisées et vous permettent de les réutiliser encore et encore. J'ai trouvé cette méthode fantastique pour une conception rapide. Je ne conçois plus non plus d'abord dans PSD mais dans le navigateur qui fait aussi gagner du temps. De plus, parce que j'ai également créé un système de nommage pour mes arrière-plans et attributs de conception de page, je change simplement mon fichier image lors de la création d'un nouveau projet. (Bg0 = arrière-plan du corps selon mon système de nommage) Cela signifie que si j'avais précédemment un blanc arrière-plan avec un projet le changer simplement en noir signifie simplement que sur le prochain projet bg0 sera un fond noir ou une autre image .....


12
Savez-vous à quoi servent les paragraphes?
Em1

C'est "UI Framework" comme Bootstrap ou autres, une fois que vous connaissez le lexique que vous êtes prêt à parcourir, tout dépend de la courbe d'apprentissage et de l'acceptation des termes utilisés. Néanmoins, je peux penser à des cas très spécifiques où votre exemple aura du mal à répondre aux exigences des concepteurs.
augurone
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.