Réduire lavitesse de chargement : est ce que ça en vaut la peine ?

[fraid26]

Réduire lavitesse de chargement : est ce que ça en vaut la p

Bonjour à tous.

Je me pose une petite question par rapport à la vitesse de chargement de mes pages :

j'ai des pages proposant des listes (fixes) comme du vocabulaire, des pays / capitales par exemple.
Chaque liste est extraite d'une base mysql dynamiquement au chargement de la page.

Voici ce que je me demandais :
est ce qu'enregistrer chaque liste dans un fichier php ou txt (mis à jour via une partie admin par exemple) en vaut la peine niveau vitesse de chargement des pages selon vous ? (référencement, bien être des visiteurs)

Je n'ai actuellement aucune stats sur la vitesse de chargement de des pages de ses listes...

Si l'un de vous a une idée, cela m'éviterais de devoir développer les scripts de calculs

Merci bonne journée !

Fred

 

[petitchevalroux]

Salut fraid 26 si tu veux tester la vitesse de chargement de ton site tu as des outils comme
yslow qui est une extension firebug ou encore en ligne webpagetest.
Si tu veux savoir si ça vaut le coup d'optimiser ton chargement tu peux lire ça.
Et sinon pour ton idée de cacher tes listes qui sont utilisées un peu partout sur ton site je dit oui c'est une bonne idée tu peux caché le résultat de ta requete dans un fichier avec un serialize par exemple. Et sinon tu peux toujours mettre un cache de page de type jpcache ou encore quicache si tu utilises du php.

 

[HawkEye]

C'est intéressant si les requêtes que tu fais sont complexes et si le trafic est non négligeable.
S'il s'agit simplement de lister le contenu d'une table, c'est une perte de temps

 

[petitchevalroux]

S'il s'agit simplement de lister le contenu d'une table, c'est une perte de temps

Mouai si c'est la liste des pays (typiquement un truc rarement modifié) je pense que dans tous les cas c'est bien de la cacher mais bon après les gouts et les couleurs .

Quand je fais un site je part du principe que moins il y a de requete moins le serveur est chargé, après si on a un site vraiment gros et que le disque dur rame a cause du cache fichier c'est deja qu'on fait un gros voir très gros traffic et alors il faut se tourner vers du memcached .

Aprés je comprend ce que veux dire HawkEye si ton site a 1000 visites jour sur un dédié, se poser des questions de cache ... c'est comme pisser dans un violon et il y a du taf autrement plus important à faire dessus comme du contenu du réferencement ....

 

[raljx]

je plussoie la remarque de HawkEye, tu as le temps de te poser la question de la vitesse... (bien entendu en fonciton de ton trafic)

 

[Bigb06]

Optimiser la vitesse de chargement des pages est un plus non négligeable (cf les liens cités par petitchevalroux)

Optimiser la vitesse de chargement pour améliorer le référencement, personne n'en parle. Personnellement j'y crois.

Hypothèse : Les crawlers de google calculent combien de pages vont être crawlées et quelles pages vont être crawlées en fonction de plusieurs critères:
- nombre de pages du site
- nombre de nouvelles pages / nombre de pages du site
- temps de réponse du site
- temps de téléchargement des pages du site
- résolution dns

Comme le crawler est une ressource partagée et qu'il doit s'occuper d'un grand nombre de sites dans une journée, google a dès le départ essayé d'optimiser son fonctionnement (cf la thèse sur la création de google). Il va donc accorder un crédit temps (ou crédit page) pour chaque site. Par exemple : le robot va crawler 12 pages ou va crawler pendant 2 minutes. Le processus est extrêmement simplifié mais on voit bien que le temps de téléchargement des pages du site est un facteur d'indexation. Le temps de réponse du site dépend de plusieurs facteurs qui sont le plus souvent externes, et la résolution dns doit très peu intervenir.
Plus les pages sont légères et rapides à indexer, plus le crawler va pouvoir en télécharger pendant son crédit temps accordé au site. Ce n'est en rien une preuve, mais google fournit dans les webmaster tools des statistiques sur le téléchargement des pages (exploration du site).

Partant de cette hypothèse, il y a plusieurs choses à vérifier/optimiser :
- le plus important et le plus simple, activer la compression HTTP (mod deflate sur apache) pour diminuer le temps de téléchargement des pages
- mettre en cache. Plus on cache (cache de bas niveau vs cache php par ex.), plus on gagne (le mieux est de cacher la page entière).
- indiquer à google quelles objets sont statiques : les images du template du site, le css et les fichiers javascript peuvent très souvent avoir une date d'expiration dans le futur (2015 par ex.) ce qui va permettre à google de ne jamais retélécharger (ou revérifier si les etags sont activés) un fichier statique. Lorsqu'il y a une modification à faire, il suffit de changer la version du fichier : script_v1.js sera renommé script_v2.js.

Dans tout les cas YSlow est un outil très utile pour mettre en place ces optimisations. Et bien sur le blog performance.

 

[Ganf]

La chose certaine par contre c'est que ça joue sur le SEM : http://adwords.blogspot.com/2008/03/lan ... on-be.html

En gros la performance de la page ciblé influe sur le quality score, et donc sur le prix de vos adword. Et ca c'est du certifié officiel avec le tampon Google comme info.

 

[ofaurax]

Je dirai oui : une site plus rapide, c'est un internaute heureux.
C'est toujours énervant (même un petit peu) quand un site rame (même un petit peu).

Pour la mesure, une estimation grossière peut être faite en enregistrant les micro-secondes en PHP à plusieurs moments de la page (ex: début, avant requête, après requête, fin) et en calculant les différences, pour savoir quoi optimiser, et si l'optimisation a marché.

 

[Ganf]

justement non Ofaurax.

Le temps ressenti par l'utilisateur n'est que très peu relié au temps de génération du code HTML par PHP. Sauf si vous avez un gros problème (qui n'a pas besoin de millisecondes pour être mesuré), le temps que tu mesures ainsi représente entre 1% et 10% au mieux du temps ressenti par l'utilisateur.

Un des premiers éléments qu'on tente d'imposer à l'esprit de chaque personne qui s'intéresse au sujet, c'est que justement le backend (ce que tu mesures en PHP) est franchement négligeable en comparaison du reste (sauf bien sur si tu fais d'énormes boulettes ou si ton serveur n'est pas adapté)

 

[ofaurax]

C'est vrai, je sais, mais il a parlé d'un site avec des listes issues de BdD, et donc j'en ai déduit que c'était principalement du texte, et que donc le temps ressenti par l'utilisateur est proche du temps génération + envoi.

Après, il n'a pas dit s'il affichait des drapeaux à côté des villes, hein....

 

[u73256]

« Réduire lavitesse de chargement : est ce que ça en vaut la peine ? »
Il suffit de bourrer les pages d'une centaine d'images de 2 à 3 Mo chacune et de les réduire via une CSS pour les afficher sous forme de vignettes et c'est tout bon.

 

[IBuzzyou]

Je pense aussi que réduire le temps de chargement des pages est un facteur de positionnement dans les SERPs car Google compte sur la satisfaction des internautes, non ?

Mais auriez-vous des astuces pour ce type d'optimisation ? Tout ce qui est à suivre, mon site est trop lent...