Ma question ne concerne pas uniquement le PHP.
Elle est un peu plus large mais je pense qu'elle a sa place ici, désolé si
ce n'est pas le cas.
Je souhaiterais optimiser mon site afin d'améliorer les temps de chargements
des pages.
Selon vous, qu'est ce qui est le plus couteux?
- Trop de php
- Trop de requètes mysql
- Trop de gifs dans la page (beaucoup mais tout petits)
- Des grosses images (peu mais assez gros)
- Des iframes.
Quelle est la répercutions exacte des connexion/déconnexion à la base SQL en
terme de performances (vaut-il mieux une connexion en début de page et une
déco à la fin ou une connexion/deconnexion à chaque requete?)
Bref, à votre avis, qu'est ce qui est le plus préjudiciable et par
conséquent que vaut-il mieux optimiser en premier?
Si vous avez des astuces de toute sorte, je suis preneur aussi bien sur :)
Est-ce qu'il existe un outil qui permettrait de savoir précisément le temps
que prends chaque opération que fait IE pour afficher la page? (analyse du
script, chargement des images, analyse de l'html, etc...)
En gros un truc comme V-Tune pour ceux qui connaissent...
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Frederic Rouchouze
Selon vous, qu'est ce qui est le plus couteux? - Trop de php - Trop de requètes mysql - Trop de gifs dans la page (beaucoup mais tout petits) - Des grosses images (peu mais assez gros) - Des iframes.
Déjà, il faut que tu saches si le temps de chargement constaté par l'utilisateur est dû : - à l'exécution de ton script PHP sur le serveur (PHP, SQL, etc.), - au chargement des éléments HTML du serveur vers le client (code HTML, images, etc.).
Pour cela, il faut que tu mesures le temps d'exécution de ton script (du début à la fin) avec une classe spécialisée ou bien la fonction microtime(). Si le temps d'exécution est de 0,1s et que ton browser met 30s à charger la page, ce n'est pas la peine d'optimiser ton code PHP ! -- Frédéric Rouchouze mailto:
Selon vous, qu'est ce qui est le plus couteux?
- Trop de php
- Trop de requètes mysql
- Trop de gifs dans la page (beaucoup mais tout petits)
- Des grosses images (peu mais assez gros)
- Des iframes.
Déjà, il faut que tu saches si le temps de chargement constaté par
l'utilisateur est dû :
- à l'exécution de ton script PHP sur le serveur (PHP, SQL, etc.),
- au chargement des éléments HTML du serveur vers le client (code HTML,
images, etc.).
Pour cela, il faut que tu mesures le temps d'exécution de ton script (du
début à la fin) avec une classe spécialisée ou bien la fonction microtime().
Si le temps d'exécution est de 0,1s et que ton browser met 30s à charger la
page, ce n'est pas la peine d'optimiser ton code PHP !
--
Frédéric Rouchouze
mailto:fredchou@nospam.free.fr
Selon vous, qu'est ce qui est le plus couteux? - Trop de php - Trop de requètes mysql - Trop de gifs dans la page (beaucoup mais tout petits) - Des grosses images (peu mais assez gros) - Des iframes.
Déjà, il faut que tu saches si le temps de chargement constaté par l'utilisateur est dû : - à l'exécution de ton script PHP sur le serveur (PHP, SQL, etc.), - au chargement des éléments HTML du serveur vers le client (code HTML, images, etc.).
Pour cela, il faut que tu mesures le temps d'exécution de ton script (du début à la fin) avec une classe spécialisée ou bien la fonction microtime(). Si le temps d'exécution est de 0,1s et que ton browser met 30s à charger la page, ce n'est pas la peine d'optimiser ton code PHP ! -- Frédéric Rouchouze mailto:
Christophe, Elite-grafx
Salut,
Selon vous, qu'est ce qui est le plus couteux?
- Trop de php
Ca depend comment tes scripts sont organisés, codés, etc... En general le melange HTML et PHP ne fait pas bon menage, adopter un systeme de template, bien organiser tes scripts, etc.. peut faire la difference D'ailleurs pour parler de HTML avant de voir comment PHP est optimisé, en partant d'une mise en page grace aux CSS, tu gagnes deja un sacré % de poids. C'est a mon avis la 1ere chose a envisager quand on parles d'optimisation de code.
- Trop de requètes mysql
Encore une fois cela depends de quoi et comment sont effectués tes requetes. Exemple tout bete : Si tu fais un "SELECT * FROM ...." sur une table qui a 42 champs, ca risque de ne pas etre super optimisé. L'idée est de faire une requete ciblée, par exemple si tu souhaite juste recuper un id et un nom, tu feras "SELECT id, nom FROM ...." La tu optimiseras ta requete beaucoup mieux.
- Trop de gifs dans la page (beaucoup mais tout petits)
Oui et non, geres les par CSS si tu peux (Si ce sont des petites images decoratives) comme ca une fois la feuille de style appelée, tout le reste du site n'aura plus besoin de les recharger a nouveau. Fais des tests de poids d'images egalement, un gif n'a souvent pas besoin d'utiliser toutes les couleurs si celui-ci est tres petit. Tu peux aussi comparer leur poids avec d'autres formats comme PNG qui fait la meme chose en mieux (AMHA)
- Des grosses images (peu mais assez gros)
Meme chose que ci-dessus. Si ce sont des images decoratives, alors direction CSS, si ce sont des images appartenant pleinement au contenu, alors tu n'as pas le choix. Et a mon avis pour repondre aussi a ta question, c'est ce qui ralentira le plus un site, de grosses images, pas toujours utiles, ou pas optimisés pour le Web (A savoir par exemple que la fonction de Photoshop "Sauver pour le Web" permet de gagner un sacré % en poids d'images.)
- Des iframes.
La je ne te reponds pas car je n'en sais rien je ne les utilises pas, et sincèrement, ce ne sont pas des pratiques conseillés pour des raisons d'accessibilité et cie...
Quelle est la répercutions exacte des connexion/déconnexion à la base SQL en
terme de performances (vaut-il mieux une connexion en début de page et une déco à la fin ou une connexion/deconnexion à chaque requete?)
Techniquement, il y a peut etre des gens qui te repondront mieux que moi. Moi perso je fais 1 connection le plus tot possible en pconnect (Permanente) et je garde la connexion jusqu'a ce que ca ne soit plus necessaire. Cela depends aussi du site a mon avis, pour de tres grosses structures complexes il faudrait mieux etre sur de la methode, donc je laisses les specialistes te repondre
Bref, à votre avis, qu'est ce qui est le plus préjudiciable et par conséquent que vaut-il mieux optimiser en premier?
Moi je commencerai par les images, ensuite, une bonne structure de fichiers organisés autour d'un moteur de Template avec ces derniers en HTML & CSS, ajoutes a ceci la generation de certains elements du site par des classes et fonctions PHP éprouvés et ca devrait faire l'affaire pour une bonne optimisation.
En esperant avoir repondu au moins partiellement a tes questions
Christophe
Salut,
Selon vous, qu'est ce qui est le plus couteux?
- Trop de php
Ca depend comment tes scripts sont organisés, codés, etc...
En general le melange HTML et PHP ne fait pas bon menage, adopter un systeme
de template, bien organiser tes scripts, etc.. peut faire la difference
D'ailleurs pour parler de HTML avant de voir comment PHP est optimisé, en
partant d'une mise en page grace aux CSS, tu gagnes deja un sacré % de
poids. C'est a mon avis la 1ere chose a envisager quand on parles
d'optimisation de code.
- Trop de requètes mysql
Encore une fois cela depends de quoi et comment sont effectués tes requetes.
Exemple tout bete : Si tu fais un "SELECT * FROM ...." sur une table qui a
42 champs, ca risque de ne pas etre super optimisé.
L'idée est de faire une requete ciblée, par exemple si tu souhaite juste
recuper un id et un nom, tu feras "SELECT id, nom FROM ...." La tu
optimiseras ta requete beaucoup mieux.
- Trop de gifs dans la page (beaucoup mais tout petits)
Oui et non, geres les par CSS si tu peux (Si ce sont des petites images
decoratives) comme ca une fois la feuille de style appelée, tout le reste du
site n'aura plus besoin de les recharger a nouveau. Fais des tests de poids
d'images egalement, un gif n'a souvent pas besoin d'utiliser toutes les
couleurs si celui-ci est tres petit. Tu peux aussi comparer leur poids avec
d'autres formats comme PNG qui fait la meme chose en mieux (AMHA)
- Des grosses images (peu mais assez gros)
Meme chose que ci-dessus. Si ce sont des images decoratives, alors direction
CSS, si ce sont des images appartenant pleinement au contenu, alors tu n'as
pas le choix.
Et a mon avis pour repondre aussi a ta question, c'est ce qui ralentira le
plus un site, de grosses images, pas toujours utiles, ou pas optimisés pour
le Web (A savoir par exemple que la fonction de Photoshop "Sauver pour le
Web" permet de gagner un sacré % en poids d'images.)
- Des iframes.
La je ne te reponds pas car je n'en sais rien je ne les utilises pas, et
sincèrement, ce ne sont pas des pratiques conseillés pour des raisons
d'accessibilité et cie...
Quelle est la répercutions exacte des connexion/déconnexion à la base SQL
en
terme de performances (vaut-il mieux une connexion en début de page et une
déco à la fin ou une connexion/deconnexion à chaque requete?)
Techniquement, il y a peut etre des gens qui te repondront mieux que moi.
Moi perso je fais 1 connection le plus tot possible en pconnect (Permanente)
et je garde la connexion jusqu'a ce que ca ne soit plus necessaire.
Cela depends aussi du site a mon avis, pour de tres grosses structures
complexes il faudrait mieux etre sur de la methode, donc je laisses les
specialistes te repondre
Bref, à votre avis, qu'est ce qui est le plus préjudiciable et par
conséquent que vaut-il mieux optimiser en premier?
Moi je commencerai par les images, ensuite, une bonne structure de fichiers
organisés autour d'un moteur de Template avec ces derniers en HTML & CSS,
ajoutes a ceci la generation de certains elements du site par des classes et
fonctions PHP éprouvés et ca devrait faire l'affaire pour une bonne
optimisation.
En esperant avoir repondu au moins partiellement a tes questions
Ca depend comment tes scripts sont organisés, codés, etc... En general le melange HTML et PHP ne fait pas bon menage, adopter un systeme de template, bien organiser tes scripts, etc.. peut faire la difference D'ailleurs pour parler de HTML avant de voir comment PHP est optimisé, en partant d'une mise en page grace aux CSS, tu gagnes deja un sacré % de poids. C'est a mon avis la 1ere chose a envisager quand on parles d'optimisation de code.
- Trop de requètes mysql
Encore une fois cela depends de quoi et comment sont effectués tes requetes. Exemple tout bete : Si tu fais un "SELECT * FROM ...." sur une table qui a 42 champs, ca risque de ne pas etre super optimisé. L'idée est de faire une requete ciblée, par exemple si tu souhaite juste recuper un id et un nom, tu feras "SELECT id, nom FROM ...." La tu optimiseras ta requete beaucoup mieux.
- Trop de gifs dans la page (beaucoup mais tout petits)
Oui et non, geres les par CSS si tu peux (Si ce sont des petites images decoratives) comme ca une fois la feuille de style appelée, tout le reste du site n'aura plus besoin de les recharger a nouveau. Fais des tests de poids d'images egalement, un gif n'a souvent pas besoin d'utiliser toutes les couleurs si celui-ci est tres petit. Tu peux aussi comparer leur poids avec d'autres formats comme PNG qui fait la meme chose en mieux (AMHA)
- Des grosses images (peu mais assez gros)
Meme chose que ci-dessus. Si ce sont des images decoratives, alors direction CSS, si ce sont des images appartenant pleinement au contenu, alors tu n'as pas le choix. Et a mon avis pour repondre aussi a ta question, c'est ce qui ralentira le plus un site, de grosses images, pas toujours utiles, ou pas optimisés pour le Web (A savoir par exemple que la fonction de Photoshop "Sauver pour le Web" permet de gagner un sacré % en poids d'images.)
- Des iframes.
La je ne te reponds pas car je n'en sais rien je ne les utilises pas, et sincèrement, ce ne sont pas des pratiques conseillés pour des raisons d'accessibilité et cie...
Quelle est la répercutions exacte des connexion/déconnexion à la base SQL en
terme de performances (vaut-il mieux une connexion en début de page et une déco à la fin ou une connexion/deconnexion à chaque requete?)
Techniquement, il y a peut etre des gens qui te repondront mieux que moi. Moi perso je fais 1 connection le plus tot possible en pconnect (Permanente) et je garde la connexion jusqu'a ce que ca ne soit plus necessaire. Cela depends aussi du site a mon avis, pour de tres grosses structures complexes il faudrait mieux etre sur de la methode, donc je laisses les specialistes te repondre
Bref, à votre avis, qu'est ce qui est le plus préjudiciable et par conséquent que vaut-il mieux optimiser en premier?
Moi je commencerai par les images, ensuite, une bonne structure de fichiers organisés autour d'un moteur de Template avec ces derniers en HTML & CSS, ajoutes a ceci la generation de certains elements du site par des classes et fonctions PHP éprouvés et ca devrait faire l'affaire pour une bonne optimisation.
En esperant avoir repondu au moins partiellement a tes questions
Christophe
Francois Girault
Selon vous, qu'est ce qui est le plus couteux?
- Trop de php - Trop de requètes mysql - Trop de gifs dans la page (beaucoup mais tout petits) - Des grosses images (peu mais assez gros) - Des iframes.
oO ... d'un manière générale, le "trop" de quelque chose est toujours couteux !
Quelle est la répercutions exacte des connexion/déconnexion à la base SQL en terme de performances (vaut-il mieux une connexion en début de page et une déco à la fin ou une connexion/deconnexion à chaque requete?) l'ouverture d'une connexion base de données est toujours lente. c'est
pour cela que l'on peut définir un paramètre dans le php.ini pour rendre les connexions persitantes et les garder d'une requête http à l'autre.
En POO, un grand classique est de créer un singleton afin de ne stocker qu'une seule et unique instance de la connexion et de prévenir les réouvertures inutiles. D'une manière plus modeste, une variable globale correctement initialisé en début de script peut faire l'affaire.
Bref, à votre avis, qu'est ce qui est le plus préjudiciable et par conséquent que vaut-il mieux optimiser en premier?
La propreté de l'accès aux données est incourtournable, les accès base coûtent cher.
Pour ce qui est coté client, cad images, iframes, etc ... enregistre la page, upload-là qqpart et regarde le temps de chargement et d'interprétation de la page. il *faut* une maquette statique de référence pour comprendre la loudeur de ce qu'on demande à html. Il y a aussi des bidouilles javascript pour charger des images en arrière-plan, mais d'autres forums seront plus apte à répondre.
Si vous avez des astuces de toute sorte, je suis preneur aussi bien sur :)
Est-ce qu'il existe un outil qui permettrait de savoir précisément le temps que prends chaque opération que fait IE pour afficher la page? (analyse du script, chargement des images, analyse de l'html, etc...) En gros un truc comme V-Tune pour ceux qui connaissent... ça non, je ne connais pas, mais le module xdebug par exemple peut te
fournir la pile d'éxécution des appels php et le temps d'éxécution de chaque appel. Indispensable à la compréhension des goulots d'étranglement dans les perfs des scripts serveurs :)
http://xdebug.org/
Merci d'avance pour vos lumières.
Bah ici c'est pas EDF, on ne doit pas plus que la lumière :)
-- FG
Selon vous, qu'est ce qui est le plus couteux?
- Trop de php
- Trop de requètes mysql
- Trop de gifs dans la page (beaucoup mais tout petits)
- Des grosses images (peu mais assez gros)
- Des iframes.
oO ... d'un manière générale, le "trop" de quelque chose est toujours
couteux !
Quelle est la répercutions exacte des connexion/déconnexion à la base SQL en
terme de performances (vaut-il mieux une connexion en début de page et une
déco à la fin ou une connexion/deconnexion à chaque requete?)
l'ouverture d'une connexion base de données est toujours lente. c'est
pour cela que l'on peut définir un paramètre dans le php.ini pour rendre
les connexions persitantes et les garder d'une requête http à l'autre.
En POO, un grand classique est de créer un singleton afin de ne stocker
qu'une seule et unique instance de la connexion et de prévenir les
réouvertures inutiles. D'une manière plus modeste, une variable globale
correctement initialisé en début de script peut faire l'affaire.
Bref, à votre avis, qu'est ce qui est le plus préjudiciable et par
conséquent que vaut-il mieux optimiser en premier?
La propreté de l'accès aux données est incourtournable, les accès base
coûtent cher.
Pour ce qui est coté client, cad images, iframes, etc ... enregistre la
page, upload-là qqpart et regarde le temps de chargement et
d'interprétation de la page. il *faut* une maquette statique de
référence pour comprendre la loudeur de ce qu'on demande à html. Il y a
aussi des bidouilles javascript pour charger des images en arrière-plan,
mais d'autres forums seront plus apte à répondre.
Si vous avez des astuces de toute sorte, je suis preneur aussi bien sur :)
Est-ce qu'il existe un outil qui permettrait de savoir précisément le temps
que prends chaque opération que fait IE pour afficher la page? (analyse du
script, chargement des images, analyse de l'html, etc...)
En gros un truc comme V-Tune pour ceux qui connaissent...
ça non, je ne connais pas, mais le module xdebug par exemple peut te
fournir la pile d'éxécution des appels php et le temps d'éxécution de
chaque appel. Indispensable à la compréhension des goulots
d'étranglement dans les perfs des scripts serveurs :)
http://xdebug.org/
Merci d'avance pour vos lumières.
Bah ici c'est pas EDF, on ne doit pas plus que la lumière :)
- Trop de php - Trop de requètes mysql - Trop de gifs dans la page (beaucoup mais tout petits) - Des grosses images (peu mais assez gros) - Des iframes.
oO ... d'un manière générale, le "trop" de quelque chose est toujours couteux !
Quelle est la répercutions exacte des connexion/déconnexion à la base SQL en terme de performances (vaut-il mieux une connexion en début de page et une déco à la fin ou une connexion/deconnexion à chaque requete?) l'ouverture d'une connexion base de données est toujours lente. c'est
pour cela que l'on peut définir un paramètre dans le php.ini pour rendre les connexions persitantes et les garder d'une requête http à l'autre.
En POO, un grand classique est de créer un singleton afin de ne stocker qu'une seule et unique instance de la connexion et de prévenir les réouvertures inutiles. D'une manière plus modeste, une variable globale correctement initialisé en début de script peut faire l'affaire.
Bref, à votre avis, qu'est ce qui est le plus préjudiciable et par conséquent que vaut-il mieux optimiser en premier?
La propreté de l'accès aux données est incourtournable, les accès base coûtent cher.
Pour ce qui est coté client, cad images, iframes, etc ... enregistre la page, upload-là qqpart et regarde le temps de chargement et d'interprétation de la page. il *faut* une maquette statique de référence pour comprendre la loudeur de ce qu'on demande à html. Il y a aussi des bidouilles javascript pour charger des images en arrière-plan, mais d'autres forums seront plus apte à répondre.
Si vous avez des astuces de toute sorte, je suis preneur aussi bien sur :)
Est-ce qu'il existe un outil qui permettrait de savoir précisément le temps que prends chaque opération que fait IE pour afficher la page? (analyse du script, chargement des images, analyse de l'html, etc...) En gros un truc comme V-Tune pour ceux qui connaissent... ça non, je ne connais pas, mais le module xdebug par exemple peut te
fournir la pile d'éxécution des appels php et le temps d'éxécution de chaque appel. Indispensable à la compréhension des goulots d'étranglement dans les perfs des scripts serveurs :)
http://xdebug.org/
Merci d'avance pour vos lumières.
Bah ici c'est pas EDF, on ne doit pas plus que la lumière :)
-- FG
Chewee
Merci à tout le monde pour vos réponses vraiment très interessantes...
Merci à tout le monde pour vos réponses vraiment très interessantes...
Merci à tout le monde pour vos réponses vraiment très interessantes...
m-e-
"Chewee" a écrit dans le message de news: 4322f153$0$29443$ [...]
Quelle est la répercutions exacte des connexion/déconnexion à la base SQL en terme de performances (vaut-il mieux une connexion en début de page et une déco à la fin ou une connexion/deconnexion à chaque requete?)
Bref, à votre avis, qu'est ce qui est le plus préjudiciable et par conséquent que vaut-il mieux optimiser en premier? [...]
Sur l'aspect profiling de PHP : J'ai vu quelqu'un parler d'XDebug, il y a aussi APD (http://pecl.php.net/package/apd). Je crois que tous deux peuvent générer des données de profiling au format Callgrind Profile Format* , visualisable par KCachegrind (http://kcachegrind.sourceforge.net/cgi-bin/show.cgi). Bon, cela nécessite les librairies KDE**, mais le résultat est impressionnant.
** on peut avoir ça sous Windows grâce à cygwin : http://www.sklar.com/blog/archives/42-PHP-5,-Xdebug-2,-and-KCachegrind-on-Windows.html
"Chewee" <padmail@news.free.fr> a écrit dans le message de news:
4322f153$0$29443$636a15ce@news.free.fr...
[...]
Quelle est la répercutions exacte des connexion/déconnexion à
la base SQL en
terme de performances (vaut-il mieux une connexion en début de
page et une
déco à la fin ou une connexion/deconnexion à chaque requete?)
Bref, à votre avis, qu'est ce qui est le plus préjudiciable et
par
conséquent que vaut-il mieux optimiser en premier?
[...]
Sur l'aspect profiling de PHP :
J'ai vu quelqu'un parler d'XDebug, il y a aussi APD
(http://pecl.php.net/package/apd). Je crois que tous deux
peuvent générer des données de profiling au format Callgrind
Profile Format*
, visualisable par KCachegrind
(http://kcachegrind.sourceforge.net/cgi-bin/show.cgi). Bon, cela
nécessite les librairies KDE**, mais le résultat est
impressionnant.
"Chewee" a écrit dans le message de news: 4322f153$0$29443$ [...]
Quelle est la répercutions exacte des connexion/déconnexion à la base SQL en terme de performances (vaut-il mieux une connexion en début de page et une déco à la fin ou une connexion/deconnexion à chaque requete?)
Bref, à votre avis, qu'est ce qui est le plus préjudiciable et par conséquent que vaut-il mieux optimiser en premier? [...]
Sur l'aspect profiling de PHP : J'ai vu quelqu'un parler d'XDebug, il y a aussi APD (http://pecl.php.net/package/apd). Je crois que tous deux peuvent générer des données de profiling au format Callgrind Profile Format* , visualisable par KCachegrind (http://kcachegrind.sourceforge.net/cgi-bin/show.cgi). Bon, cela nécessite les librairies KDE**, mais le résultat est impressionnant.
