Temps de connexion au serveur très long

WRInaute discret
Bonjour,

En testant l'un de mes sites grâce à Pingdom Tools (http://fpt.pingdom.com/#!/uChNuht49/petitsjobs.ch), j'ai constaté que pour extrêmement beaucoup de fichiers, ce qui ralentissait le plus le chargement était le temps de connexion (en bleu) !

Je me pose donc la question : d'où provient cette lenteur, est-elle normale, peut-on faire quelque chose pour réduire cette durée ?

Actuellement, je suis sur un serveur mutualisé. J'ai l'intention de passer prochainement en dédié mais je me demandais si cela allais permettre de considérablement réduire ce temps.

Sinon, j'ai vu que la barre jaune de beaucoup de fichiers, wait, était aussi plutôt grande même lorsqu'il s'agit de simples images ==> il n'y a donc pas d'attente sur un script PHP. Un meilleur serveur aiderait-il également ?

Bien sûr, quand on regarde le temps de chargement des scripts de Facebook, ils tendent vers 0... Leur serveur est beaucoup plus puissant, mais est-ce la seule raison ?

Merci d'avance :)

7804j
 
WRInaute accro
Au lieu d'utiliser un site externe pour ce genre de tests je te conseille d'intaler firebug dans un firefox qui te donne la même chose et bien plus sans laisser de sale traces sur le web avec ton domaine. Ceci étant dit voici ce que j'obtiens chez moi :

1.4 MB
(250.4 KB à partir du cache)
13s (onload: 13.26s)

C'est lourd (1.4 Mb) et c'est très très lent, 13 secondes bref ça fait fuir tous le monde. La turie se trouve dans les innombrables javascripts que tu charge (externe ou pas) et dans les images qui sont un peut lourdes.

Ton score page speed (encore un plugin a ajouter mais c'est rentable) est mauvais (69/100) mais pas catastrophique pour autant (j'ai vue pire) il dénote des optimisations possible comme :

▸ Enable compression [Score: 33/100]
▸ Leverage browser caching [Score: 0/100]
▸ Defer parsing of JavaScript [Score: 89/100]
▸ Minify JavaScript [Score: 69/100]
▸ Combine images into CSS sprites [Score: 71/100]
▸ Optimize images [Score: 55/100]
▸ Optimize the order of styles and scripts

Pour arriver a bien mettre en oeuvre tout cela il n'est pas certains que ton mutu t'en donne les moyens.
Ceci dit ce qui devrait te décider a passer au dédié n'est pas là. ton site peut encore faire mieux (pense au cahche par exemple en plus) et seulement quand tu aura tout optimisé là c'est ton trafic et l'espace necessaire qu'il faudra observer pour passer a plus gros.
Note aussi qu'un dédié premier prix mal géré c'est moins perf qu'un mutu de qualité super optimisé.
 
WRInaute impliqué
Autant essayer d'optimiser au maximum avant de basculer éventuellement sur un dédié. La compression, la réduction du nombre de fichiers et le poids des fichiers sont les points les plus importants.
 
WRInaute discret
Merci pour tes conseils. Cependant ma question était plutôt pour ce qui concerne les ralentissements côté serveur que côté client, qui ne peuvent eux, pas être mis en avant par PageSpeed. Néanmoins, PageSpeed est de loin le meilleur dans son domaine ! J'avais utilisé d'autres outils du genre mais ils ne donnaient pas autant de détails et de facilité.

Tu pourras voir sur mes deux sites, http://www.petitsjobs.ch et http://www.dofus2.org que le PageSpeed tourne désormais entre 80 et 90. J'ai constaté qu'il variait d'un chargement à l'autre, est-ce normal ?

J'ai tout de même quelques questions.

Déjà, j'ai remarqué que PageSpeed conseillait de compresser les images. Pour chaque image à compresser, PageSpeed nous donne directement la même image en format compressé. Mais pourtant, j'ai remarqué que l'image était bien moins vive et avait donc clairement perdu en qualité, alors que l'outil affirme qu'il n'y a aucune perte de ce côté-là ! L'outil ne serait donc pas encore au point ?

Sinon, PageSpeed me demande à chaque fois "Exploiter la mise en cache du navigateur". Ce qui me semble étrange puisque je croyais que le navigateur le faisait automatiquement en regardant la date de la dernière modification de chaque fichier (envoyée par le serveur). Alors comment dois-je m'y prendre ? N'est-il pas possible de faire que les fichiers soient toujours en cache sauf quand la date de dernière modification du fichier est changée par le serveur (donc quand je renvoie le fichier par FTP avec FilleZilla) ?

J'ai encore remarqué que pour beaucoup de conseils de PageSpeed, je devais effectuer des actions sur des scripts de Google, tel que Google Adsense et Analytics. Je suis tout de même étonné que ceux-ci ne soient pas optimisés selon les conseils de leur propre outil.


Sinon, pour revenir au sujet de base, même après ces optimisations on trouve cela :
http://fpt.pingdom.com/#!/v1GrIk2eb/petitsjobs.ch
http://fpt.pingdom.com/#!/oJWg9Qow1/dofus2.org

Comme avant, les barres bleues des fichiers, représentant le temps nécessaire au navigateur UNIQUEMENT pour se connecter au serveur est extrêmement long. C'est pour cela que je me posais la question du serveur dédié.

Merci d'avance,

7804j
 
WRInaute accro
861.9 KB
(216.7 KB à partir du cache)
13.35s (onload: 13.72s)

ça reste lent chez moi (en cas de chargement complet de la page donc sans cache ou presque Ctrl + F5)

7804j a dit:
Tu pourras voir sur mes deux sites, http://www.petitsjobs.ch et http://www.dofus2.org que le PageSpeed tourne désormais entre 80 et 90. J'ai constaté qu'il variait d'un chargement à l'autre, est-ce normal ?
Il te reste 5 points exploitables tu peux encore gagner du temps.

7804j a dit:
Déjà, j'ai remarqué que PageSpeed conseillait de compresser les images. Pour chaque image à compresser, PageSpeed nous donne directement la même image en format compressé. Mais pourtant, j'ai remarqué que l'image était bien moins vive et avait donc clairement perdu en qualité, alors que l'outil affirme qu'il n'y a aucune perte de ce côté-là ! L'outil ne serait donc pas encore au point ?
Plus tu souhaitera de la qualité plus tu aura de détail mais plus ton image sera lourde. Le résultat est une histoire de compromis et comme tu en utilise beaucoup forcement ça prend du temps. regarde sur les autres formats possibles pour les images peut être que tu trouvera un compromis plus acceptable. Sinon ce n'est pas que l'outil est au point ou pas c'est juste qu'il te donnera toujours une version plus optimisée jusqu'a ne plus rien voir sur l'image.

7804j a dit:
Sinon, PageSpeed me demande à chaque fois "Exploiter la mise en cache du navigateur". Ce qui me semble étrange puisque je croyais que le navigateur le faisait automatiquement en regardant la date de la dernière modification de chaque fichier (envoyée par le serveur). Alors comment dois-je m'y prendre ? N'est-il pas possible de faire que les fichiers soient toujours en cache sauf quand la date de dernière modification du fichier est changée par le serveur (donc quand je renvoie le fichier par FTP avec FilleZilla) ?

pageSpeed a dit:
The following cacheable resources have a short freshness lifetime. Specify an expiration at least one week in the future for the following resources:

* http://www.petitsjobs.ch/app/Roar.js (expiration not specified)
* http://www.petitsjobs.ch/app/TableGear1.6.1-MooTools/javascripts/Table ... ooTools.js (expiration not specified)
* http://www.petitsjobs.ch/app/formcheck/formcheck.js (expiration not specified)
* http://www.petitsjobs.ch/app/formcheck/lang/fr.js (expiration not specified)
* http://www.petitsjobs.ch/app/jQuery-UI/js/jquery-ui-1.8.16.custom.min.js (expiration not specified)
Ton serveur envoie un entête pour tout. C'est a toi de faire en sorce que la date de peremption de tes images (et des javascript et des CSS etc ...) soit sufisante pour que le navigateur concidère qu'il n'est pas necessaire de les recharger a chaque page.

Par exemple cette image : http://www.petitsjobs.ch/images/etudiant.png renvoie ça :

Date Sat, 29 Oct 2011 11:35:37 GMT
Server Apache/2.2.X (OVH)
Last-Modified Sun, 29 May 2011 12:11:00 GMT
Etag "4955eb5-15827-4a469106a960c"
Accept-Ranges bytes
Content-Length 88103
Content-Type image/png

Une image optimisée pour un cache renvoie ça :
Date Sat, 29 Oct 2011 11:50:26 GMT
Server Apache
Cache-Control max-age=290304000, public
Last-Modified Mon, 24 Oct 2011 11:15:52 GMT
Etag "60df9133-4c2d4-4ea548e8"
Accept-Ranges bytes
Content-Length 312020
Content-Type image/jpeg
Observe bien la ligne Cache-Control :
un code php peut se charger de ça avec les lignes du style :
Code:
	// header jpg
	$offset = 290304000;
	$expire = gmdate ("D, d M Y H:i:s", time() + $offset) . " GMT";
	header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT");
	header("Cache-Control: max-age=$offset, public");
	header("expires: ".$expire);
	header('Content-Type: image/jpeg');
ou simplement un htaccess du type :
Code:
	<FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf|PNG)$">
	Header set Cache-Control "max-age=290304000, public"
	</FilesMatch>

c'est sur ces points qu'il faut voir si ton mutu te permet cela. Sinon le cache de ton navigateur (ou du miens) fonctionne avec les info d'en tête. il mettra en cache ce qui peut l'être et pas le reste. Donc tant que tu ne modifiera pas tes entêtes, il n'exploitera pas son cache de façon optimum comme les autre équipements en route. Attention, l'utilisation du cache a un corolaire. Si tes données sont dans un cache du web il est fort probable qu'un équipement X ou Y comme un site X ou Y (google ou Face Book par exemple) n'ai pas accès a la dernière version de ta page (c'est courant quand je partage une page de mes sites sur FaceBook, il ne détecte pas la dernière version de la page et me donne des photos qui n'existent plu).

7804j a dit:
J'ai encore remarqué que pour beaucoup de conseils de PageSpeed, je devais effectuer des actions sur des scripts de Google, tel que Google Adsense et Analytics. Je suis tout de même étonné que ceux-ci ne soient pas optimisés selon les conseils de leur propre outil.
Il y a des points que lesquels il ne peuvent pas agir et pour lesquel tu ne pourra rien (sauf a héberger chez toi ce qui peut l'être), par exemple spécifier un cache long pour un javascript qui évolue souvent et hégergé chez eux peut être dangereux (une version buguée resterait longtemps). Il faut savoir qu'entre ton serveur et le navigateur de ton visiteur il y a une miriade d'équipements qui eux aussi exploitent les headers des fichiers pour savoir si ils peuvent se permettre de conserver un fichier ou si il doivent tous le temps renvoyer une version "Clean" moralité pour ce genre de truc le serveur de référence peut demander que ses documents ne soit pas mis en cache.

7804j a dit:
Comme avant, les barres bleues des fichiers, représentant le temps nécessaire au navigateur UNIQUEMENT pour se connecter au serveur est extrêmement long. C'est pour cela que je me posais la question du serveur dédié.
La je ne sais trop quoi dire. je pense que le temps de connection est lié a la résolution DNS plus le temps que le serveur accepte la connection donc si ton mutu est mal placé il est pas certains qu'un dédié soit mieux.

Defer parsing of JavaScript -> trop de code directement dans la page c'est pas bon.
Trop de saut de ligne et de tabulations dans le code source de la page aussi tu devrais faire le ménage en plus d'utiliser des caractères pour rien ça rend le code illisible donc difficile a maintenir ou étudier.
 
WRInaute occasionnel
Salut !

Sinon concernant les images lourdes à charger : Pourquoi ne pas utiliser un serveur "dédié" au stockage et au chargement de tes images ?

A l'image de youtube et de ses vidéos, cela permettrait de ne pas alourdir ton serveur "dédié" à l'hébergement de ton site ...
 
WRInaute discret
zeb a dit:
861.9 KB
(216.7 KB à partir du cache)
13.35s (onload: 13.72s)

ça reste lent chez moi (en cas de chargement complet de la page donc sans cache ou presque Ctrl + F5)
Je ne comprend pas comment tu arrives à ces 13,35 secondes, je n'ai jamais eu de temps aussi long sur aucun des ordinateurs que j'ai utilisés, peu importe le réseau wifi. Surtout que même si ça peut faire pas mal pour un site, 861 kb ça fait même pas 1mb donc...
zeb a dit:
7804j a dit:
Tu pourras voir sur mes deux sites, http://www.petitsjobs.ch et http://www.dofus2.org que le PageSpeed tourne désormais entre 80 et 90. J'ai constaté qu'il variait d'un chargement à l'autre, est-ce normal ?
Il te reste 5 points exploitables tu peux encore gagner du temps.
Je sais que je peux gagner du temps. Il faudrait surtout regarder au niveau du cache et des sprites. Ce que je trouve quand même bizarre, c'est que le pagespeed varie de 80 à 90 et change à chaque fois que je recharge la page : il est pas fixe.

zeb a dit:
7804j a dit:
Déjà, j'ai remarqué que PageSpeed conseillait de compresser les images. Pour chaque image à compresser, PageSpeed nous donne directement la même image en format compressé. Mais pourtant, j'ai remarqué que l'image était bien moins vive et avait donc clairement perdu en qualité, alors que l'outil affirme qu'il n'y a aucune perte de ce côté-là ! L'outil ne serait donc pas encore au point ?
Plus tu souhaitera de la qualité plus tu aura de détail mais plus ton image sera lourde. Le résultat est une histoire de compromis et comme tu en utilise beaucoup forcement ça prend du temps. regarde sur les autres formats possibles pour les images peut être que tu trouvera un compromis plus acceptable. Sinon ce n'est pas que l'outil est au point ou pas c'est juste qu'il te donnera toujours une version plus optimisée jusqu'a ne plus rien voir sur l'image.
Non, justement. Selon l'outil, il devrait s'agir d'une version compressée sans perte de qualité ! Ce n'a pourtant pas l'air d'être le cas.

zeb a dit:
7804j a dit:
Sinon, PageSpeed me demande à chaque fois "Exploiter la mise en cache du navigateur". Ce qui me semble étrange puisque je croyais que le navigateur le faisait automatiquement en regardant la date de la dernière modification de chaque fichier (envoyée par le serveur). Alors comment dois-je m'y prendre ? N'est-il pas possible de faire que les fichiers soient toujours en cache sauf quand la date de dernière modification du fichier est changée par le serveur (donc quand je renvoie le fichier par FTP avec FilleZilla) ?

pageSpeed a dit:
The following cacheable resources have a short freshness lifetime. Specify an expiration at least one week in the future for the following resources:

* http://www.petitsjobs.ch/app/Roar.js (expiration not specified)
* http://www.petitsjobs.ch/app/TableGear1.6.1-MooTools/javascripts/Table ... ooTools.js (expiration not specified)
* http://www.petitsjobs.ch/app/formcheck/formcheck.js (expiration not specified)
* http://www.petitsjobs.ch/app/formcheck/lang/fr.js (expiration not specified)
* http://www.petitsjobs.ch/app/jQuery-UI/js/jquery-ui-1.8.16.custom.min.js (expiration not specified)
Ton serveur envoie un entête pour tout. C'est a toi de faire en sorce que la date de peremption de tes images (et des javascript et des CSS etc ...) soit sufisante pour que le navigateur concidère qu'il n'est pas necessaire de les recharger a chaque page.

Par exemple cette image : http://www.petitsjobs.ch/images/etudiant.png renvoie ça :

Date Sat, 29 Oct 2011 11:35:37 GMT
Server Apache/2.2.X (OVH)
Last-Modified Sun, 29 May 2011 12:11:00 GMT
Etag "4955eb5-15827-4a469106a960c"
Accept-Ranges bytes
Content-Length 88103
Content-Type image/png

Une image optimisée pour un cache renvoie ça :
Date Sat, 29 Oct 2011 11:50:26 GMT
Server Apache
Cache-Control max-age=290304000, public
Last-Modified Mon, 24 Oct 2011 11:15:52 GMT
Etag "60df9133-4c2d4-4ea548e8"
Accept-Ranges bytes
Content-Length 312020
Content-Type image/jpeg
Observe bien la ligne Cache-Control :
un code php peut se charger de ça avec les lignes du style :
Code:
	// header jpg
	$offset = 290304000;
	$expire = gmdate ("D, d M Y H:i:s", time() + $offset) . " GMT";
	header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT");
	header("Cache-Control: max-age=$offset, public");
	header("expires: ".$expire);
	header('Content-Type: image/jpeg');
ou simplement un htaccess du type :
Code:
	<FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf|PNG)$">
	Header set Cache-Control "max-age=290304000, public"
	</FilesMatch>

c'est sur ces points qu'il faut voir si ton mutu te permet cela. Sinon le cache de ton navigateur (ou du miens) fonctionne avec les info d'en tête. il mettra en cache ce qui peut l'être et pas le reste. Donc tant que tu ne modifiera pas tes entêtes, il n'exploitera pas son cache de façon optimum comme les autre équipements en route. Attention, l'utilisation du cache a un corolaire. Si tes données sont dans un cache du web il est fort probable qu'un équipement X ou Y comme un site X ou Y (google ou Face Book par exemple) n'ai pas accès a la dernière version de ta page (c'est courant quand je partage une page de mes sites sur FaceBook, il ne détecte pas la dernière version de la page et me donne des photos qui n'existent plu).
Justement, c'est ce que je disais. Le serveur renvoie dans les en-têtes la date de dernière modification :
Last-Modified Mon, 24 Oct 2011 11:15:52 GMT

D'après ce que j'ai compris sur le fonctionnement des navigateurs récents, il me semblait qu'ils étaient capable de décider par eux-même d'enregistrer ce fichier dans le cache jusqu'à ce que ce last-modified change. Enfin maintenant, je n'en connais pas les limites...

Je vais donc voir ce que je peux faire pour la gestion du cache. Mais maintenant, imaginons que je mette un cache de 2 mois sur certaines images et que, tout à coup, je les modifie sans pour autant en changer le nom : comment faire pour expliquer au navigateur qu'il doit recharger l'image et ne pas utiliser le cache ?

zeb a dit:
7804j a dit:
J'ai encore remarqué que pour beaucoup de conseils de PageSpeed, je devais effectuer des actions sur des scripts de Google, tel que Google Adsense et Analytics. Je suis tout de même étonné que ceux-ci ne soient pas optimisés selon les conseils de leur propre outil.
Il y a des points que lesquels il ne peuvent pas agir et pour lesquel tu ne pourra rien (sauf a héberger chez toi ce qui peut l'être), par exemple spécifier un cache long pour un javascript qui évolue souvent et hégergé chez eux peut être dangereux (une version buguée resterait longtemps). Il faut savoir qu'entre ton serveur et le navigateur de ton visiteur il y a une miriade d'équipements qui eux aussi exploitent les headers des fichiers pour savoir si ils peuvent se permettre de conserver un fichier ou si il doivent tous le temps renvoyer une version "Clean" moralité pour ce genre de truc le serveur de référence peut demander que ses documents ne soit pas mis en cache.
Ok, c'est effectivement ça mais ça me semblait bizarre dans certains cas. Enfin bon, ça reste de faible importance.

zeb a dit:
7804j a dit:
Comme avant, les barres bleues des fichiers, représentant le temps nécessaire au navigateur UNIQUEMENT pour se connecter au serveur est extrêmement long. C'est pour cela que je me posais la question du serveur dédié.
La je ne sais trop quoi dire. je pense que le temps de connection est lié a la résolution DNS plus le temps que le serveur accepte la connection donc si ton mutu est mal placé il est pas certains qu'un dédié soit mieux.
Oui, je pense qu'il s'agit de la résolution DNS. Effectivement, le serveur étant placé en France c'est possible que ça soit dû à ça car le lieu du test était aux USA.
zeb a dit:
Defer parsing of JavaScript -> trop de code directement dans la page c'est pas bon.
Trop de saut de ligne et de tabulations dans le code source de la page aussi tu devrais faire le ménage en plus d'utiliser des caractères pour rien ça rend le code illisible donc difficile a maintenir ou étudier.
[/quote]
Euh...Excuse-moi mais defer parsing of JavaScript ça veut dire qu'il faut le séparer et ne pas tout mettre dans <head>. En l'occurrence, c'est pas trop possible parce que tous mes scripts ont besoin d'être chargés avant l'affichage :/

Enfin merci quand même pour tes conseils. Je crois que le plus important c'est surtout de gérer cette histoire de cache.
 
WRInaute discret
lunicrea a dit:
Salut !

Sinon concernant les images lourdes à charger : Pourquoi ne pas utiliser un serveur "dédié" au stockage et au chargement de tes images ?

A l'image de youtube et de ses vidéos, cela permettrait de ne pas alourdir ton serveur "dédié" à l'hébergement de ton site ...

Tu veux dire un domaine dédié, un second hébergement ou un serveur dédié à proprement parler ?
 
WRInaute accro
Non, justement. Selon l'outil, il devrait s'agir d'une version compressée sans perte de qualité ! Ce n'a pourtant pas l'air d'être le cas.
<mode-humour>Je suis désolé de devoir te l'apprendre sans prendre le temps d'y mettre les formes mais le père Noël n'existe pas.</mode-humour>

Je vais donc voir ce que je peux faire pour la gestion du cache. Mais maintenant, imaginons que je mette un cache de 2 mois sur certaines images et que, tout à coup, je les modifie sans pour autant en changer le nom : comment faire pour expliquer au navigateur qu'il doit recharger l'image et ne pas utiliser le cache ?
Tu en as beaucoup des scripts JS CSS et des images qui changent ? Sinon bah il n'y a rien a faire pour forcer le changement c'est le navigateur qui le fera tout seul (si il est pas idiot). Il y deux concepts a bien voir :

le Cache-Control max-age qui indique la durée possible de mise en cache.
et Last-Modified qui indique la dernière modification. donc si le navigateur, routeur ou autre est capable de se dire "Last-Modified" + "Cache-Control max-age" > à "maintenant" je donne / exploite la version cache il sera capable de se dire :

"Last-Modified" a changé j'update mes données. Enfin je suppose...

Euh...Excuse-moi mais defer parsing of JavaScript ça veut dire qu'il faut le séparer et ne pas tout mettre dans <head>. En l'occurrence, c'est pas trop possible parce que tous mes scripts ont besoin d'être chargés avant l'affichage :/
Je pense que tu as "defer loading of JavaScript" dans la tête et pas "parsing".
Pour que les JS soit chargés avant l'affichage il faut justement les mettre dans le Head ... ensuite envoyer un ordre peut se faire n'importe ou.
defer parsing of JavaScript a dit:
Overview

In order to load a page, the browser must parse the contents of all <script> tags, which adds additional time to the page load. By minimizing the amount of JavaScript needed to render the page, and deferring parsing of unneeded JavaScript until it needs to be executed, you can reduce the initial load time of your page.

Peut être que je comprend pas bien (normal franco français je me suis jamais remis de l'histoire de Jeanne), mais a priori il est plus saint de mettre ton code en fichier, de le charger dans le head et ensuite dans le body de mettre de courtes balises / commandes, commandant juste ce don tu as besoins.

http://code.google.com/intl/fr/speed/page-speed/docs/mobile.html#DeferParsingJS
 
WRInaute discret
Ok, merci.

Non, je ne crois pas au père noël mais je pense que tu connais le principe d'une compression gz, zip, etc. Bah pour les images c'est la même chose, y'en a des qui sont mal optimisés et qu'on pourrait compresser en gardant le même résultat.

Je cite :

Si vous compressez http://petitsjobs.ch/images/etudiant.png sans perte, vous pourriez libérer 12.1 Ko (réduction de 15%). See optimized version.

Il est bien écrit sans perte.

Images saved from programs like Fireworks can contain kilobytes of extra comments, and use too many colors, even though a reduction in the color palette may not perceptibly reduce image quality. Improperly optimized images can take up more space than they need to; for users on slow connections, it is especially important to keep image sizes to a minimum.

Les images contiennent parfois des commentaires qui peuvent être retirés. Des fois, elles ont été mal enregistrées, également, mais l'outil de Google ne fais pas que des modifs invisibles :/

Enfin bon, c'est pas grave :)
 
WRInaute occasionnel
7804j a dit:
Tu veux dire un domaine dédié, un second hébergement ou un serveur dédié à proprement parler ?
A priori, l'architecture technique de Youtube serait un domaine dédié au sein d'un serveur dédié en utilisant un système de cache ... Même si concrètement c'est beaucoup plus complexe que ça ! :)

Ce qu'on sait c'est que c'est découpé suivant ce procédé avec d'un coté le serveur web et de l'autre le serveur de vidéos.

Donc, te concernant tu remplaces le serveur de vidéos par celui d'images.

Plein d'infos en cherchant un peu sur Google "architecture de youtube" ;)
 
WRInaute discret
Oui, c'est effectivement un principe très courant utilisé par les grands sites, surtout quand ceux-ci mettent à disposition des ressources très volumineuses. On héberge distinctement le texte, le contenu etc. des ressources (images, vidéos voire scripts css et js).

Enfin bon, dans mon cas c'est pas aussi important :/

Sinon, aurais-tu un lien spécifique pour Youtube ? Bien sûr, de nombreux sites parlent de son architecture mais je ne trouve pas mention de ce dont tu parles.
 
WRInaute impliqué
Il y a encore beaucoup de choses à faire:
utilisation de jquery et mootools : ne pouvez vous pas supprimer l'une ou l'autre des bibliothèques? il y a une quantité impressionnante de fichiers js chargés, sans doute pour pas grand chose
4 fichiers CSS: ne pouvez vous pas regrouper l'ensemble dans un seul fichier?
boutons twitter, google+ et widget facebook : sont-ils vraiment utiles à ce stade du projet?
 
Discussions similaires
Haut