Utiliser XLT pour vos pages 404

Un petit truc que l’on oublie souvent lorsque l’on a un beau blog WordPress (et tout autre site d’ailleurs), c’est d’aller jeter un œil régulièrement à  toutes les éventuelles erreurs que l’on a involontairement (ou pas) généré. Je vous passe tous les arguments sassés et ressassés de notre grand ami à  tous, l’inénarrable Google, qui nous prêche que des pages que l’on ne peut accéder (les fameuses 404), ce n’est pas bien pour notre référencement. J’acquiesce bien entendu dans cette direction, si ce n’est que je me permet d’ajouter un petit détail: avant de ne pas être bien pour notre précieux référencement, ce n’est surtout pas bien pour nos précieux visiteurs.

Donc, si j’éconduis mon visiteur vers quelque chose qui n’est pas en corrélation avec ses attentes, à  savoir une super truc de la mort-qui-tue-et-qui-permet-de-gagner-1000-euros-par-jour-sans-rien-faire, à  savoir une de ces horribles pages 404, c’est triste pour lui et donc en conséquence, c’est également triste pour moi.

Comme le plugin XLT semble avoir conquis le cœur de certain d’entre vous, je me suis dit que c’était là  une occasion unique de contourner l’épineux problème que je viens de soulever: puisqu’une page 404, c’est moche, c’est pas bien, ni pour vous, ni pour la Grande Inquisition, autant qu’elle serve à  quelque chose, et qu’elle maximalise la visite de toutes les formidables personnes qui viennent trainer leur guêtres sur ce modeste blog.

Par   conséquence, je vais subodorer que vous utilisez mon plugin XLT, et que vous pour le bien de tous, vous avez francisé vos pages 404. Vous insérez alors le code PHP que je vous ai mis plus bas qui proposera à  quiconque tentant d’accéder à  une ressource inexistante de votre beau blog, une de ces fameuses pages pas assez visitées et estimées par le plugin XLT. Ce qui devrait vous octroyer un supplément de trafic non négligeable et puis aussi faire revivre quelques-uns de vos articles ressurgis d’outre-tombe.

Vous pouvez tenter un petit test de facto en tentant d’accéder à  l’URL inexistante suivante: https://www.pagasa.net/tartelette

J’en profite pour vous dire que, ô grande surprise, certains moteurs de recherche inspectent vos pages 404 et vont jusqu’à  extraire les liens qui y sont contenus; c’est le cas de Bing par exemple.

Ci-dessous, le code à  insérer dans votre fichier 404.php:

<?php 
global $wpdb;

$sql = $wpdb->get_results("SELECT $wpdb->posts.ID FROM $wpdb->posts WHERE $wpdb->posts.post_status='publish' AND $wpdb->posts.post_type = 'post' ORDER BY $wpdb->posts.ID DESC LIMIT 1");
   foreach ($sql as $res) {
       $j = $res->ID;
   }

   $sql = $wpdb->get_results("SELECT $wpdb->posts.ID FROM $wpdb->posts WHERE $wpdb->posts.post_status='publish' AND $wpdb->posts.post_type = 'post' ORDER BY $wpdb->posts.ID LIMIT 1");
   foreach ($sql as $res) {
       $mid = $res->ID;
   }
   $mx = 10;
   $nx = 0;

   $m = "";
   $i = 0;
   while ($nx != $mx) {
       $md = $wpdb->get_var("SELECT COUNT(*) FROM ".$wpdb->prefix . "pk_kw WHERE postid = '".$mid."'");
       if(!$md) {
           $mpost = get_post($mid);
           $murl = get_permalink($mid);
           $mtags = wp_get_post_tags($mid);
           $mkw = "";
           $l = 0;
           foreach($mtags as $mtag) {
               if($l<4)
                   $mkw .= $mtag->name. " ";
               $l++;
           }
           if(!strlen($mkw)) {
               $mkw = $mpost->post_title;
       }
           $m .= $mhd2.'<h4><a href="'.$murl.'"'.' title="'.$mkw.'">'.$mpost->post_title."</a></h4>".$mhd3;
           $nx++;
       }
       else
           $i++;
       $sql = $wpdb->get_results("SELECT $wpdb->posts.ID FROM $wpdb->posts WHERE $wpdb->posts.post_status='publish' AND $wpdb->posts.post_type = 'post' AND $wpdb->posts.ID > $mid ORDER BY $wpdb->posts.ID LIMIT 1");
       foreach ($sql as $res) {
           $mid = $res->ID;
       }
       if($i == $j)
           $nx = $mx;
   }
   echo $m;
?>

Mise à  jour du Popunder

Je viens de mettre à  jour mon script Popunder suite à  certains problèmes rencontrés par ses utilisateurs.

Tout d’abord, un petit bug fâcheux effaçait régulièrement le fichier popunder.dat qui contient vos liens à  afficher en popunder: les accès concurrents à  ce fichier ont été mis en place afin de résoudre ce petit souci. Je rappelle que les liens contenus dans ce fichier sont en rotation et que c’est là  une technique très pratique pour isoler vos meilleures conversions. Pour ma part, j’utilise généralement des lots de trois sites que je renouvelle de temps en temps.

Ensuite, vous pouvez maintenant centraliser votre fichier popunder.dat: si vous avez par exemple une dizaine de sites sur lesquels vous souhaitez utiliser le script popunder, il est sans doute plus commode d’avoir une seule copie de vos liens au même endroit. Pour ce faire, indiquez simplement l’URL du site qui héberge le fichier. Ceci se fait en modifiant la variable $url qui se trouve au début du script, comme ceci:

$url ="https://www.pagasa.net/";

Bien entendu, si vous ne souhaitez pas le faire, laissez la variable vide. A notez que si vous utilisez la centralisation, le script ira également chercher le fichier popunder.js sur le site central; ce qui vous évite d’avoir à  le distribuer.

Edit du 30 octobre 2013: je viens de modifier légèrement le code suite à  un autre petit souci. Mettez à  jour le script.

Téléchargez le popunder

Un Popunder efficace et performant

Je vous livre ici le script du Popunder que j’utilise et que je trouve particulièrement efficace. Souvent décrié, le Popunder est beaucoup moins intrusif que son cousin, le Popup. On peut l’utiliser sur de l’affiliation mais aussi pour faire connaitre un site tout neuf; c’est un excellent moyen de drainer de nouveaux visiteurs et ainsi promouvoir un site.

Le Popunder ouvre une page de votre choix derrière la page courante, et ce au premier clic de souris. Le script génère également un cookie d’une journée qui limite ainsi sa sur-utilisation. Ce script a été utilisé avec succès sur IE et Firefox autorisant le Javascript.

Pour l’utiliser, décompressez l’archive à  la racine de votre site. Le fichier popunder.dat comprend les liens vers lesquels vous voulez orienter vos visiteurs. A noter que ces liens sont en rotation, vous permettant ainsi de tester ce qui vous convient le mieux en terme de performance ou de diversité. N’hésitez donc pas à  mettre plusieurs liens dans ce fichier.

Le fichier popunder.php est le script php que vous copiez/collez juste avant votre </body> et qui va appeler le code Javascript (voir fichier popunder.js). Pour WordPress, il faut que vous l’insériez dans le fichier footer.php qui se trouve dans le répertoire wp-content/themes/votre-thème.

Laissez le fichier popunder.js à  la racine de votre site sans toucher à  son contenu. Ce fichier contient le code du Popunder; il a déjà  été minifié pour des raisons de performance.

Téléchargez le popunder

Les mots de passe utilisés sur l’attaque brute force de WordPress

Cela fait maintenant plusieurs semaines que je subis régulièrement des attaques à  coup de brute force sur Pagasa. Certes, cela ne m’empêche pas trop de dormir car mon mot de passe est très complexe, même si cela ne garantit pas forcément la sécurité du blog mais cela perturbe un peu mes statistiques.

Pour passer le temps, je me suis livré à  un petit jeu: j’ai crée mon propre wp-login.php, le script cible de l’attaque, pour analyser un peu plus ce que font toutes ces machines Zombies. J’ai pu ainsi récupéré un nombre très important de mots de passe utilisés lors de cette attaque. Si votre mot de passe apparait dans cette liste, vous êtes donc potentiellement susceptibles de vous faire hacker. Vous devez donc immédiatement changer le mots passe de votre blog.
 

L’optimisation des performances d’un site Web

Cela fait maintenant quelques années que j’ai changé ma stratégie en terme de référencement. J’ai finir par laisser tomber mes vieilles techniques Blackhat pour me consacrer à  d’autres techniques plus pérennes, telle que celle de la longue traine ou encore la construction de liens via les réseaux sociaux. Les résultats de ce changement de direction sont visibles directement au travers de mon site qui marche. Au sujet de ce dernier, les résultats sont toujours croissants mais j’ai pu observer une très légère baisse de trafic sans doute suite à  la dernière mise à  jour de l’algorithme de Google. Mais globalement, la tendance reste bonne.

L’optimisation des performances du site web

Récemment, je me suis penché sur un autre aspect que j’avais jusqu’à  lors assez négligé: l’optimisation des performances du site. Il est établi depuis déjà  longtemps qu’un site qui réagit rapidement est plus apprécié par Google qu’un site qui se comporte en limace rhumatisante. D’après mes observations, cette caractéristique est bien souvent laissée de côté par la plupart des gens qui se focalisent beaucoup plus sur la promotion de leur site au travers de la construction de liens. C’est dommage, car un site bien optimisé, performant et qui se charge rapidement peut décoller et même gagner des places dans les SERPS.

Je me suis donc rendu sur la pléiade de sites qui vous propose un rapport sur les performances de votre propre site afin de pouvoir creuser cette idée et aussi bien entendu d’apporter les modifications nécessaire lorsque cela s’avère possible. En fait, ce n’est pas toujours évident car lorsque vous utilisez un CMS assez lourd comme par exemple WordPress, vous êtes tributaire d’un code tiers, de plugins mal codés, de thèmes mal optimisés, etc. Il faut parfois revoir totalement certaines choses carrément dans le code PHP pour arriver à  une saine optimisation. A noter toutefois que pour WordPress, il existe des plugins qui peuvent vous aider dans ce genre de démarche.

Dans un premier temps, je me suis donc plutôt focalisé sur mon site qui marche car je suis complétement maitre de tout le code qu’il utilise. Suite à  toutes ces optimisations, voici les résultats que me donnent Webpagetest.

webpagetest

Les premiers octets sont très importants

Le « First Byte Time » correspond au temps qu’il faut pour qu’un client obtienne d’un serveur son premier octet. Ce n’est pas forcément évident à  optimiser car il existe une grande dépendance à  la bande passante et c’est quelque chose que l’on ne maitrise absolument pas à  moins d’y mettre le prix. Mais on peut travailler sur l’optimisation de la page principale afin de réduire au maximum son temps d’accès. Dans le cas du site qui marche, cette page est générée par un script PHP que j’ai modifié. D’abord en le réduisant à  sa plus simple expression, en supprimant par exemple un maximum de lignes blanches, de commentaires et aussi en utilisant une indentation différente. J’ai aussi supprimé les include qui sont évidemment gourmands en entrée-sortie. Cela m’a obligé à  utiliser des constantes directement dans le corps du programme, ce qui n’est bien évidemment pas des plus recommandés et franchement pas pratique. Après plusieurs tests, je me suis rendu compte que ces changements n’apportaient pas beaucoup d’améliorations dans la vitesse d’accès à  la page. Les optimisations de type minification semblent beaucoup trop négligeables lorsqu’elles sont effectuées côté serveur.   Je pense qu’il vaut mieux essayer d’optimiser au mieux les accès goulus telles que ceux que l’on pratique en base de données, voir même de créer un système de cache maison. Je ferai cela à  l’occasion dans le cadre de la refonte de mon code.

Activez les connexions persistantes

Le « Keep-alive Enabled » correspond à  la mise en place d’une connexion socket dite persistante. Lorsque vous communiquez avec un serveur Web, vous établissez en fait une connexion TCP sur le port 80 (ou 443 si vous passez en SSL), vous envoyez la commande GET pour avoir votre page HTML, le serveur vous envoie les données et ferme la connexion. Si vous faites une autre demande, le serveur ouvrira une nouvelle connexion. Sur une connexion persistante, vous choisissez de ne pas fermer la connexion et de poursuivre le dialogue en vue d’obtenir d’autres éléments HTML, avec comme conséquence un gain non négligeable en performance. Ceci se fait très facilement sur Apache en insérant la directive keepalive dans la configuration de votre site web. Et pour votre culture, sachez que Sendmail fait cela également au travers d’un mécanisme appelé « cache de connexion ».

Compressez les données lors du transfert des pages

Le « Compress transfert » indique qu’une compression est utilisée lors du transfert de l’information depuis votre serveur vers votre navigateur. Bien entendu, celui-ci doit être capable de supporter les mécanismes de compression. Fort heureusement , la plupart des navigateurs le prenne en compte désormais. Néanmoins pour voir si votre navigateur est compatible avec la compression de transfert, il suffit de décoder le trafic Web avec par exemple le plugin Firefox Live HTTP Header et de voir sir votre navigateur envoie la directive suivante: Accept-Encoding: gzip, deflate. Du côté du serveur, pour activer la compression sous Apache, il suffit d’ajouter les directives suivantes dans votre .htaccess:

AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript

BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
Header append Vary User-Agent

La problématique des images

L’ensemble de la gestion des images est une problématique à  elle toute seule tant il y a dire à  ce sujet et les possibilités pour l’optimisation sont légion. La première chose à  savoir est le bon choix du format de l’image. Dans mon cas particulier, c’est le format PNG qui donne les meilleurs résultats. En passant par exemple du GIF ou du JPEG vers ce format, j’ai pu réduire de 10% la taille des images avec la même qualité visible. On peut aussi gagner des précieux kilo-octets en réduisant le nombre de couleurs utilisées, ou en supprimant le blanc souvent utilisé comme délimiteur. Les sites d’optimisation recommandent également de bien préciser les dimensions des images afin que le navigateur n’ait pas à  lui même refaire un formatage des données ou une nouvelle mise en page. Finalement, il est tout à  fait envisageable de réduire drastiquement l’overhead du protocole HTTP utilisé lors de l’envoi des images. L’overhead est la quantité supplémentaire d’informations nécessaire au transport d’une seule information. Par exemple: dois-je nécessairement envoyer des cookies lors de l’affichage unique d’une image ? Dois-je préciser l’URL de provenance (referer) ? Dois-je afficher d’autres informations superflues ? La solution à  cette problématique repose dans le déport de toutes mes images vers un site spécialisé. Je crée donc un sous domaine, par exemple images.pagasa.net, qui va se charger de l’affichage optimisé de mes images. Dedans, je piloterai l’envoi de mes images en évitant soigneusement tout overhead inutile.

La minification des données

Il s’agit ici sans doute de la partie la plus facile à  réaliser dans l’immédiat. La minification consiste simplement à  « compresser manuellement » toutes vos données, et ceci se fait de manière très aisée. Prenez une page Web, et observez son contenu. Vous allez vous rendre compte qu’il y a un très grand nombre d’informations que vous pouvez d’ores et déjà  effacer. Par exemple, les lignes blanches, des espaces en veux-tu en voilà  et un certain nombre d’autres choses qui n’affecte en rien l’affichage, comme les commentaires par exemple. Vous pouvez faire de même avec vos fichiers CSS ou votre code Java.

De mauvais résultats à  cause des scripts extérieurs

Le mauvais résultat obtenu sur le cache statique provient des applets Java utilisés par des éditeurs extérieurs tels que Google pour Adsense et Analytic. Là  encore une fois, il n’est pas possible d’y remédier: vous êtes entièrement tributaires de leur performance. On est tout de même en droit de se poser la question de leur légitimité finalement: pour avoir un site entièrement performant, il ne faut donc pas utiliser d’applets externes.

En conclusion, je suis assez bluffé de toutes les possibilités qui me sont offertes pour optimiser le site Web. Rappelez-vous que Google est très sensible à  la rapidité de l’accès à  votre site Web; donc ne négligez pas cet aspect. Pour terminer, voici une petite liste des sites que j’ai utilisé afin d’effectuer mes tests de performance: