Discussion :

[-aAdrien]

Bonjour à tous,

en regardant sur PingDom, je me suis aperçu que l'essentiel du temps de chargement de mon blog (http://abcmoteur.fr) était utilisé par index.php.
On s'en rend très bien compte : http://fpt.pingdom.com/#!/http://abcmoteur.fr/

Apparemment il y aurait le plugin Wordpress Popularity Contest qui utiliserait index.php.

Comment faire ?

[manu_71]

Je n'ai pas vraiment compris quel est ton soucis ?
Sur un blog wordpress, toutes tes pages ou presque passent par index.php mais c'est un fonctionnement normal... Par contre si c'est un problème de lenteur, soit ça vient de l'hébergeur qui rame, soit effectivement peut-être un plug-in quelconque qui fait ramer, soit...

[-aAdrien]

Je sais que index.php est utile.

Mais déjà une question : pourquoi fais-je partie des seuls blogs qui affichent index.php sur pingdom ?

[manu_71]

Je ne vois pas où tu as vu que j'ai dit qu'il est utile. D'ailleurs il n'est pas utile mais indispensable ! J'ai juste dit que si tu demandais pourquoi ça passait tous par index.php, c'était un fonctionnement normal de wordpress.
Après comme je te l'ai dit, je n'ai pas compris ta question de base...

[-aAdrien]

J'essaye de mieux expliquer alors.

Il y a deux points :
- pourquoi index.php apparaît lors d'un test avec le site PingDom ? 99 % des blogs Wordpress l'affichent pas
- pourquoi index.php prend tout le temps de chargement du blog ?

On m'a parlé d'erreur 500 et 404 dans mes js sous firebug onglet réseau mais je les vois pas...

[manu_71]

Je ne connais pas pingdom pour répondre à ta première question... (mais j'aurais un peu tendance à dire qu'on s'en moque non ? En fait tout dépend si pingdom accède à l'adresse du site ou bien index.php... ce qui revient au même au final). Et le fait que je ne sache pas comment fonctionne pingdom ça va conditionner ma 2ème réponse :
Si pingdom se base sur le poids du fichier, ça signifie que c'est sans doute le plus lourd. Mais encore une fois, il faut voir ce qu'il considère... le fichier seul ? le fichier avec les images, les scripts inclus, etc ? Si tout est inclus, il est tout à fait logique que le fichier index.php prend plus de temps à charger que chacun des éléments que le compose.
S pingdom se base sur le temps de réponse du serveur (sans considérer la taille du fichier), ça signifie que ton serveur doit ramer un max pour fournir la page index.php (donc pour afficher ton blog). Ca peut soit venir d'un problème de l'hébergeur qui a des serveurs qui ne suivent pas (WordPress est un petit peu gourmand, m'enfin pas de quoi fouetter un chat non plus => change vite d'hébergeur !). Soit un problème sur ta page (un script, un plug-in ou je ne sais trop quoi qui rame et met du temps à s'afficher).
Du coup je suis allé voir ton blog (je ne l'avais pas encore fait n'ayant pas bien compris où tu voulais en venir). Et c'est vrai que ça rame grave ! Le chargement se déroule bien et on doit avoir 90% de la page chargée dans le cache quand subitement le serveur n'envoie plus de données... (le navigateur passe "en attente de abcmoteur.fr"). Ca dure bien facilement 1mn avant que la page finisse par s'afficher quand même au final.
Sur la source de ta page index.php, il y a tout à la fin du fichier :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<!-- Dynamic page generated in 3.496 seconds. -->

3 secondes et demi, c'est pas hyper rapide mais c'est pas la mort et en tout cas c'est pas le temps que j'ai attendu... Alors il y a bien un soucis quelque part mais je ne vois pas comment te dire où... (hébergeur ? un plug-in qui foire ?)

[-aAdrien]

Avec PingDom tout est détaillé : temps, connexion, poids, ... c'est l'idéal pour voir où ça cloche ! http://fpt.pingdom.com/#!/http://abcmoteur.fr/

Pour te répondre, tout le temps perdu avec index.php est dans le temps d'attente. Il fait même pas un kB.

A mon avis, c'est un fichier qui ne répond pas (des personnes m'ont parlé de 404 et 500 sur mon blog). Du coup, le navigateur attend puis annule.

Le problème, c'est que avec firebug je trouve pas ces erreurs 404 et 500. :s

[manu_71]

Moi non plus. Je n'ai pas vu de 404 ou 500... Après j'ai aussi remarqué que c'est super variable. Des fois la page se charge rapidement et d'autres fois non... Donc il suffit que même si on attend beaucoup, le truc qui répond pas facilement fini par répondre et on trouvera pas le 404 ou le 500... Il faut tomber sur le moment ou le serveur n'attendra plus la réponse et où tu auras ta 404 ou 500...
Sinon, faut reprendre toute ta page morceau par morceau et voir ce qui pourrait poser problème (à commencer par les trucs qui se chargent sur un serveur externe) en essayant de les commenter / désactiver pour voir si peut résoudre le problème...

Si je peux me permettre... Il y en a quand même une sacré tartine qui se charge !! T'es sûr que tout est utile ? Parce que là, bonjour le poids de la page malgré tout !

[-aAdrien]

Ca va être fastidieux mais nécessaire de tout tester.

Le problème c'est que beaucoup de plugins ont été installés puis désinstallés, le mieux serait de repartir sur une base propre en supprimant tout.
Après faudrait que j'ai une version locale.

Tu veux parler de quels éléments ? Le blog fait environ 800 ko mais pour un thème magazine c'est plutôt normal avec toutes ces images...

[manu_71]

Je ne trouve pas que 800ko soit "normal", même pour ce que tu affiches, images compris... A mon avis ça manque cruellement d'optimisations tout ça...
Repartir sur une base saine serait sans aucun doute une bonne idée et ferait un sacré ménage !
Bon courage !

[-aAdrien]

J'ai du nouveau, le problème viendrait de ces lignes

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
    <script type="text/javascript">
    jQuery(function() {
       
       jQuery.post("index.php",{ak_action:"api_record_view", ids: AKPC_IDS, type:"home"}, false, "json");
    });
    </script>

[transgohan]

J'espère que ce code est sous condition.
Parce que sinon cela implique une boucle infinie d'appel à index.php
Tu charges index.php qui envoie une requête asynchrone à index.php qui envoie une requête asynchrone à index.php qui.......

[manu_71]

En effet ! Il y a de grandes chances que le problème vient d'ici. Le comportement constaté correspondrait bien à ce problème.

[-aAdrien]

J'espère que ce code est sous condition.
Parce que sinon cela implique une boucle infinie d'appel à index.php
Tu charges index.php qui envoie une requête asynchrone à index.php qui envoie une requête asynchrone à index.php qui.......

Je me suis un peu renseigné sur les conditional tags, lequel je dois choisir de cette page http://codex.wordpress.org/Conditional_Tags ?

Autre chose, depuis 3-4 jours j'ai mon taux de rebond qui est passé de 65 à 25 %... pourtant ce problème est bien plus ancien.

Pensez-vous que ça pourrait être dû à l'installation puis désinstallation de plusieurs plugins pour google analytics ?

[transgohan]

C'est une simple condition PHP qu'il faut utiliser, les fonctions de Wordpress ne t'aideront pas.
Il faut simplement vérifier que dans $_POST ne se trouve pas ak_action = api_record_view pour exécuter ce script JS.
Ainsi tu éviteras le bouclage.