Retournez à
Accueil /
Passage à Ortegeek 2.0, optimisation du site
0
Le site Ortegeek va bientôt faire peau neuve.
Je reste sur Pluxml, qui marche toujours aussi bien, mais le thème du site va passer en version 1.5 ou 2.0 selon comment on voit les choses.
Navigation accrue, design plus uniforme, meilleure accessibilité sans pour autant changer drastiquement de la version 1.0.
Aujourd'hui, je vais vous parlez de l'optimisation du site. Une étape longue, mais qui peut faire la différence.
Favicon
L'explication sur le terme favicon.
Une petite icône qui change pas grand chose, mais qui donne un rendu final plus propre au site.
J'ai trouvé le site Real Favicon Generator qui permet de faire cela pour le web, mais aussi pour les icônes de raccourcis sur smartphone.
<link rel="apple-touch-icon" sizes="57x57" href="https://ortegeek.fr/img/apple-touch-icon-57x57.png">
<link rel="apple-touch-icon" sizes="60x60" href="https://ortegeek.fr/img/apple-touch-icon-60x60.png">
<link rel="apple-touch-icon" sizes="72x72" href="https://ortegeek.fr/img/apple-touch-icon-72x72.png">
<link rel="apple-touch-icon" sizes="76x76" href="https://ortegeek.fr/img/apple-touch-icon-76x76.png">
<link rel="apple-touch-icon" sizes="114x114" href="https://ortegeek.fr/img/apple-touch-icon-114x114.png">
<link rel="apple-touch-icon" sizes="120x120" href="https://ortegeek.fr/img/apple-touch-icon-120x120.png">
<link rel="apple-touch-icon" sizes="144x144" href="https://ortegeek.fr/img/apple-touch-icon-144x144.png">
<link rel="apple-touch-icon" sizes="152x152" href="https://ortegeek.fr/img/apple-touch-icon-152x152.png">
<link rel="apple-touch-icon" sizes="180x180" href="https://ortegeek.fr/img/apple-touch-icon-180x180.png">
<link rel="icon" type="image/png" href="https://ortegeek.fr/img/favicon-32x32.png" sizes="32x32">
<link rel="icon" type="image/png" href="https://ortegeek.fr/img/favicon-194x194.png" sizes="194x194">
<link rel="icon" type="image/png" href="https://ortegeek.fr/img/favicon-96x96.png" sizes="96x96">
<link rel="icon" type="image/png" href="https://ortegeek.fr/img/android-chrome-192x192.png" sizes="192x192">
<link rel="icon" type="image/png" href="https://ortegeek.fr/img/favicon-16x16.png" sizes="16x16">
<link rel="manifest" href="https://ortegeek.fr/img/manifest.json">
<link rel="shortcut icon" href="https://ortegeek.fr/img/favicon.ico">
<meta name="apple-mobile-web-app-title" content="Ortegeek - Culture Libriste">
<meta name="application-name" content="Ortegeek - Culture Libriste">
<meta name="msapplication-TileColor" content="#ffffff">
<meta name="msapplication-TileImage" content="/img/mstile-144x144.png">
<meta name="msapplication-config" content="/img/browserconfig.xml">
<meta name="theme-color" content="#ffffff">Import CSS ?
Dans un souci d’accélération du site, je me suis penché sur le chargement des fichiers css.
J'ai entendu parler de la fonction import qui permet à une feuille css (ou la balise <style>) d'en importer une ou plusieurs autres.
Une bonne idée quand on veut gérer la stylisation dans une seule feuille.
Malheureusement, les performances ne sont pas très bonnes, me forçant à rester sur la classique méthode de la balise <link>.
Un peu de doc pour vous convaincre :
N'utilisez pas @import - alsacreations.com
Don’t use @import - stevesouders.com
Javascript
Dans le but d'améliorer la légèreté du thème, j'ai décidé de transformer du code jQuery en Javascript brut.
Je voulais moins solliciter les ordinateurs des visiteurs et réduire la chaîne d’intermédiaire car on a pas toujours besoin d'un framework.
Je me suis alors amusé à tester les différents moteur Javascript des nombreux navigateurs.
Si la méthode querySelectorAll n'est pas la plus légère, je suis parti sur une itération de 1500 fois pour comparer au même code en jQuery.
var ite = 1500;
console.time('Function #1');
for(y = 0; y < ite; y++)
{
var aHref = document.querySelectorAll("a[href='https://ortegeek.fr/article37/passage-a-ortegeek-2-0-optimisation-du-site#']");
for(i = 0; i < aHref.length; i++){
aHref[i].onclick = function(e) { e.preventDefault(); };
}
var aExternal = document.querySelectorAll("a[rel=external]");
for(i = 0; i < aExternal.length; i++){
aExternal[i].onclick = function(e){
e.preventDefault();
if(this.href)
window.open(this.href);
};
}
}
console.timeEnd('Function #1');
console.time('Function #2');
for(y = 0; y < ite; y++)
{
$("a[href='https://ortegeek.fr/article37/passage-a-ortegeek-2-0-optimisation-du-site#']").click(function(event){
event.preventDefault();
});
$('a[rel=external]').click(function(event){
event.preventDefault();
if(this.href){
window.open(this.href);
}
});
}
console.timeEnd('Function #2');
Si mon code n'est pas des plus brillant, les résultats font réfléchir.
Firefox 40
Function #1 : 34.67ms
Function #2 : 103.91ms
Chromium 46
Function #1: 82.691ms
Function #2: 114.782ms
Vivaldi 1.0.233
Function #1: 53.647ms
Function #2: 84.237ms
Internet Explorer 11
Function #1 : 203,777 ms
Function #2 : 290,577 ms
Avant de parler de la différence entre les deux méthodes, on peut voir l'écart entre les multiples navigateurs/moteurs avec IE aux fraises, mais surtout celui entre Chromium et Vivaldi qui utilise pourtant le moteur Blink.
L'optimisation de ces moteurs crée déjà une différence ; sur Firefox, la méthode 1, dite native, prend l'avantage plus nettement que sur les autres, ce qui confirme que le suivi de Javascript est très bon sur celui-ci (kangax.github.io/compat-table/es6/).
Pour le reste, on voit un écart à l'avantage du Javascript pur, plus ou moins marqué donc.
Si ce type de fonctionnement par itération n'est pas des plus réaliste, mais il montre bien les différences qu'ils existent dans la rapidité d'exécution.
Par contre, jQuery sera plus rapide à mettre en place avec un code plus simple et sa gestion plus poussé des sélecteurs est un réel plus, sans parler de sa documentation abondante.
Pour ceux qui souhaite utiliser un framework seulement pour les sélecteurs, il existe Sizzle.
Je finis en vous laissant plusieurs comparatifs continuant d'illustrer la différence de vitesse entre Javascript/jQuery, mais aussi entre méthodes du même langage.
