L'antre de Morphée

Bien sûr, j'entends par « vision réduite » qu'ils ne conçoivent l'optimisation que dans l'optique réseau alors que le travail du serveur avant de fournir des données au réseau compte pour au moins 30% du temps de transmission. Ce travail concerne pour l'essentiel la génération de contenu par le module PHP et intrinsèquement, les accès aux bases de données (surtout si ces dernières sont gérées par un serveur/gestionnaire de base de données, SGBD, comme MySQL). Mais un site optimisé c'est aussi un site qui n'est pas trop gourmand et correctement lisible, j'y reviendrais à la fin de ce billet.

Optimisation des scripts PHP

L'optimisation des scripts PHP revient souvent à une optimisation très basiques que l'on peut appliquer à la plupart des codes sources quelque soit le langage ou pseudo-code, je n'en parlerais pas car il s'agit bêtement des optimisations que l'on apprend en cours d'algorithmie. Ce qui est propre à l'interprétation de PHP et un peu moins connu. Par exemple, l'utilisation des guillemets (doubles quotes) et des apostrophes (simples quotes) que seul les fous furieux du perfectionnisme se sont attelés à comprendre. En fait, le module PHP va lire une chaine entre guillemets comme il lirait une autre ligne de code, en la filtrant dans un parseur, ainsi $str = "L'équipe vous dit bonjour, $nom"; se verra interprété et le parseur substituera le nom de la variable par sa valeur. Le parseur interprétera aussi tous les caractères échappés avec l'antislash (\) tel que echo "\ttabulation suivi\nd'un retour à la ligne";. Alors qu'une chaine entre apostrophes sera filtrée par un parseur nettement plus léger puisque que la seule occurrence substituée sera les apostrophes échappés et pour y inclure des variables, il suffit d'utiliser la concaténation (.). Ce qui nous donne $str = 'L\'équipe vous dit bonjour '.$nom;.

Les tableau ont eux aussi des points faibles, par exemple, parcourir un tableau avec for est plus long que foreach. Je n'ai pas compris pourquoi et il semblerais que les gars de la fondation PHP ne le savent pas non plu. Conséquence imprévisible du module en production ? Autre point intéressant, l'initialisation peut se faire directement en appelant l'index $tab[0] = 10; $tab[1] = 12; plutôt quand utilisant l'objet array() qui est bien plus lourd, $tab = array(10, 12);. Quant à l'accès avec une clés non-numérique, il plus performant lorsque la clés est entre apostrophes echo $tab['cles'];.

Il faut éviter au maximum les include() et require() inutiles qui vont s'empresser de faire des ouvertures de fichiers en pagaye. Cela dit, ils sont nécessaire pour un code lisible. On peut tout de même les accélérer en leur fournissant des chemins absolus vers les fichiers. Il suffit d'utiliser $_SERVER['DOCUMENT_ROOT'] qui est systématiquement initialisé (que vous l'utilisiez ou non) et qui contient le chemin absolu de la racine du script appelé (c-à-d /var/www sur une installation non modifié). Ou vous pouvez utiliser $chemin_absolu = dirname($_SERVER['SCRIPT_FILENAME']); si votre script n'est pas dans la racine même. Notez que cela fonctionne aussi avec fopen(), opendir(), etc ... C'est tous bête mais tous cela vous fera gagner quelques précieuses millisecondes.

Des requêtes SQL mieux ciblées

Déjà, vous allez me faire le plaisir d'oublier les requêtes du style SELECT * FROM `table`; ! Le prochain que je surprend à utiliser un joker (*) dans ses requêtes SQL, je le pend par les orteils dans une cave pleine de rats. De même, n'indique dans vos requêtes que les noms des colonnes que vous utilisées. L'utilisation de « jetons » (« ` » [Alt GR] + [7è]) pour délimiter les noms de colonnes, de tables ou encore de bases de données sont, quant à eux, fortement conseillés SELECT `id`, `nom`, `prenom` FROM `table`;. L'interpréteur de MySQL semble lire les requêtes deux fois plus vite grâce aux jetons.

Lors de la création de vos tables, n'oublier pas d'attribuée l'une de vos colonnes de l'option PRIMARY et si nécessaire une autre de l'option UNIQUE. lorsque vous utilisez la commande WHERE dans vos requêtes, les colonnes affublées de l'une de ses options seront traitées bien plus vite par le moteur de MySQL.

L'extension PDO du module PHP permet des requêtes « préparées », je vous laisse le soin de voir cela sur le manuel de PHP.

Un site ni trop gourmand, ni illisible

La bonne lisibilité d'un site à toujours était énoncée lorsque l'on parle de référencement. Mais aujourd'hui, On peut voir une forme de dérive comportementale de la par des créateurs de site web dût, je pense, à la popularité du Web 2.0. Par exemple, l'abus d'image PNG de grande taille dans le design des sites et qui remplacent les informations textuelles, les rendant par la même occasion inaccessibles aux moteurs de recherche. Ou bien encore l'utilisation excessif d'AJAX et de javascript lourdant inutilement les pages et menant les sites à être tributaire de l'installation effective ou non du javascript chez le client. Pire certains site utilise l'AJAX pour afficher l'intégralité du contenu textuel qui ne sera bien sûr pas visible par les spiders de Google.

Voici quelques règles d'or pour le référencement :

• L'AJAX offre une couche applicative formidable mais parfaitement inutile pour 99% des sites web. Virez l'AJAX ! Mais gardez-le pour vos applications web et vos administrations.
• Les images du design (celle que l'on vous partout sur le site) doivent impérativement faire moins de 50ko mais surtout elles ne doivent pas remplacer les textes
• Utilisez les standards et leurs paradigmes de l'HTML/XHTML et bien sûr du CSS.
• Un contenu texte plus qu'un autre type de média. Si malgré tout vous postez une vidéo, par exemple, assurez-vous qu'elle soit accompagnée d'une description complète incluant des mots-clés.
• Un net-linking de qualité, oubliez le farm-linking.
• Seul un contenu intéressant et fréquemment mise à jour peut vous garantir un certain nombre de visites (ne faites pas comme moi sur ce blog ).

Finalement, les développeurs ont du pain sur la planche et pendant se temps les administrateurs réseaux vont casser du sucre sur notre dos...