Régler la palette de couleur par défaut du thème Divi

Régler la palette de couleur par défaut du thème Divi

Dans ce deuxième article d’une série, , je procède aux premiers réglages du thème Divi nouvellement installé sur le site de test. C’est important de s’organiser pour perdre le moins de temps possible et je me suis rendu compte que je risquais de passer des journées à ajuster les couleurs !

Une option à régler dès le début : la palette de couleurs

Beaucoup de modules, options ou éléments de personnalisation permettent de régler des couleurs. A chaque fois, une palette pré-définie est proposée, ainsi qu’un mode défaut. J’ai donc cherché où, et comment, régler la palette par défaut.

Dans le tableau de bord WordPress, menu Divi >> Options du thème, onglet « Général », on peut définir la palette par défaut, composée de 8 couleurs.

J’ai modifié les 7 couleurs autres que le blanc.

Choisir sa palette de couleur

J’ai choisi une couleur principale Violet #843bbb puis j’ai été voir quelles étaient les couleurs associées dans color-hex. Voici ce qui s’affiche :

Palette de couleur associée au Violet #843bbb selon Color-Hex

Palette de couleur associée au Violet #843bbb selon Color-Hex

 

J’ai donc décidé de mettre dans ma palette par défaut les couleurs associées en mode triadique, analogue et complémentaire – voir l’article choisir les bonnes couleurs pour un site (hexa, rgb) pour plus de précisions. Et j’ai remplacé le noir par un gris foncé #555555. Voici ma nouvelle palette par défaut :

Nouvelle palette de couleur par défaut dans Divi

Nouvelle palette de couleur par défaut dans Divi

 

Régler la palette de couleur sur « défaut »

Et maintenant, je vais personnaliser le thème (menu Apparence / personnaliser), je règle la palette de couleur sur « défaut ».

Et voilà !

Je ne perdrai pas de temps à définir les couleurs des éléments que je vais probablement créer !

Dans le prochain article de cette série , je vais tenter d’évaluer ce thème et de décider si ça vaut vraiment le coup de l’utiliser.

Utiliser le thème DIVI pour un site WordPress sur un hébergement Infomaniak

Utiliser le thème DIVI pour un site WordPress sur un hébergement Infomaniak

L’hébergement Infomaniak propose gratuitement l’accès aux thèmes d’Elegant Themes et de Woocommerce. J’ai voulu essayer d’installer le fameux thème DIVI d’Elegant Themes.

Avant de commencer, sauvegarder !

J’ai fait quelques essais sur un site de test et j’ai eu des problèmes au départ (avant de comprendre ce qui suit). Je vous recommande donc de sauvegarder les fichiers et la base de données avant toute modification.

Il faut noter que Infomaniak fait une sauvegarde automatique toutes les 24 heures. Il est cependant prudent de faire une sauvegarde manuelle de la base de données au cas où, et des fichiers de wp-content si on a fait des modifications dans les dernières 24 heures.

Installer le thème DIVI sur un site WordPress existant

J’ai installé tous les sites WordPress que j’héberge via l’installateur automatique d’Infomaniak. Je crois que l’installateur de thème ne fonctionne pas si on a créé manuellement WordPress.

Aller dans le tableau de bord Infomaniak, menu « sites web » >> « Mon site WordPress » :

Tableau de bord infomaniak : menu "Mon site WordPress"

Tableau de bord infomaniak : menu « Mon site WordPress »

Cliquer sur le bouton « Configurer » du site à modifier, puis sur le bouton « Paramètres ».

cliquer sur « changer de thème » et choisir « DIVI » :

Installer Divi sur un site WordPress hébergé par Infomaniak

Installer Divi sur un site WordPress hébergé par Infomaniak

Attention, si les cases « Importer le contenu de démonstration du thème » et « activer le nouveau thème », il y a un risque de plantage du site.

Il faut donc impérativement désactiver ces deux options, comme dans la copie d’écran ci-dessus.

Lorsqu’on clique sur « valider », le thème DIVI (et l’extension Divi Builder) s’installent sur le site mais ne sont pas activés.

Et maintenant ?

Cet article est le premier d’une série sur ce thème DIVI, . Dans le second et le troisième, j’explorerai les premiers réglages ainsi que le transfert d’options, paramètres et modèles de DIVI.

Plus tard, j’affinerai certains réglages et créerai un thème enfant pour ajouter facilement du PHP et du CSS.

optimisation de ce site : 5 secondes pour charger sur mobile, pas mal !

optimisation de ce site : 5 secondes pour charger sur mobile, pas mal !

Après avoir exploré les possibilités d’optimiser un site dans le premier article de cette série, , j’applique ce que j’ai appris à ce site. Compression de fichiers et d’images, mise en cache, réglages de l’hébergement, minification de fichiers… J’ai mis en oeuvre ce que j’avais appris. Et ce site se charge en 5 secondes sur mobile maintenant. C’est moins bien que les 2 secondes recommandées par Google, mais c’est « Good » !

L’état initial

Ce site avait déjà été un peu optimisé, et il utilise un thème récent (stargazer).

item à régler Fait ?
serveur : php 7 ou plus oui, 7.1
serveur : compression des fichiers ON
serveur : Module Google pageSpeed ON
extension smush version gratuite activée
WP superCache activée
Hummingbird NON

Les réglages du serveur étaient faits : PHP 7.1, compression GZIP et module Google PageSpeed activés.

Certaines images étaient compressées avec l’extension WP Smush gratuite et WP SuperCache assurait la mise en cache.

Il était donc déjà assez rapide. Selon TestMySite.WithGoogle, il se chargeait en 6 secondes sur mobile, ce qui est considéré comme « Fair » (correct).

Ce qui est bizarre, c’est que PageSpeed Insights donne des résultats très mauvais (66 – needs work pour mobile, 54 – Poor pour ordinateur).

Les ajustements

Je complète ce que j’avais déjà fait en suivant les instructions du premier article de cette série (Optimisation d’un site WordPress (Infomaniak, WPmuDev).

J’ai donc installé et activé WP Smush Pro et Hummingbird, puis j’ai compressé les images et réglés les paramètres d’optimisation.

Le résultat est satisfaisant : ce site se charge maintenant en 5 secondes sur mobile, ce que TestMySite de Google juge « Good » !

Chargement en 5 secondes selon Test My Site de Google !

 

Bizarrement, les mesures de PageSpeed Insights restent mauvaises, avec cependant une petite amélioration en mode mobile :

Les résultats selon Google PageSpeed Insights

Lorsque je regarde les « étapes de résolution du problème » proposées par Page Speed Insights, il me semble que les problèmes sont absolument mineurs…

Et maintenant ?

Je ne comprends pas les résultats de Page Speed Insights. Il y a donc certainement encore quelque chose que je n’ai pas bien compris… A suivre donc !

Optimisation d’un site WordPress (Infomaniak, WPmuDev)

Optimisation d’un site WordPress (Infomaniak, WPmuDev)

Dans cet article, j’explore pour la première fois l’optimisation d’un site web pour en améliorer la rapidité, tant sur mobile ou tablette que sur un ordinateur. Ce premier article d’une série, , vise seulement à lister quelques tentatives d’amélioration avec les outils, et les connaissances, dont je dispose aujourd’hui. Il sera complété par d’autres articles au fur et à mesure de mes essais, réussites et échecs.

Optimiser un site web, pourquoi ?

Je lis partout (et je l’observe dans ma pratique d’internaute) qu’un site lent à charger perd des visiteurs.

Un bon site doit s’afficher de manière quasi instantanée pour tous les visiteurs, qu’ils aient un faible débit internet ou pas, qu’ils utilisent un ordinateur, une tablette ou un téléphone.

Par ailleurs, la vitesse d’affichage d’un site est un des critères de référencement par les moteurs de recherche.

Est-ce que mon site est rapide ?

Plusieurs outils de test existent. Voici ceux que j’ai utilisés :

Optimiser un site web, comment ?

Fort heureusement, les outils de test cités donnent tous des recommandations.

Ainsi si je teste l’url « https://parcours-performance.com » avec PageSpeed Insights, j’obtiens une note, mais aussi une liste des critères d’optimisation. Pour chaque critère, j’ai des recommandations d’amélioration, et une liste précise de ce qui ne va pas, le cas échéant. Les critères sont les suivants :

Premiers essais d’optimisation

Pour le site « Parcours Performance« , j’ai commencé l’optimisation et les critères suivants sont bons, pour mobile comme pour desktop :

  • Afficher en priorité le contenu visible
  • Optimiser les images
  • Réduire la taille des ressources CSS
  • Réduire la taille des ressources HTML
  • Réduire la taille des ressources JavaScript
  • Éviter les redirections sur la page de destination

Les autres critères ne sont pas encore entièrement bons mais la note globale s’est considérablement améliorée :

  Avant Après
temps de chargement Test My Site 11 secondes (insuffisante) 9 secondes (médiocre)
Page speed Insights Mobile 54/100 (Poor) 70/100 (Needs Work)
Page speed Insights Desktop 63/100 (Poor) 79/100 (Needs Work)

Voici ce que j’ai fait pour y arriver :

Passage en PHP 7.1

Fin juillet 2017, plus de 85% des sites WordPress fonctionnaient encore avec des versions de PHP 5.6 et antérieures (voir les statistiques WordPress ici) alors que la version 7 a été lancée en décembre 2016. Il est indispensable de passer tous les sites WordPress à PHP 7 (et même 7.1) car cette nouvelle version contient des améliorations spectaculaires en matière de rapidité et de sécurité.

Ca se fait dans l’espace client (sur OVH ou Infomaniak). Auparavant, on aura pris soin de vérifier la compatibilité du site en installant l’extension « PHP Compatibility Checker » qui permet de mettre en lumière des difficultés.

Activation d’une extension de mise en cache

J’utilise « WP Super Cache« , qui est proposée par défaut sur les installations WordPress d’Infomaniak. Si on ne l’a pas, Il suffit de l’installer et activer. Les réglages par défaut sont satisfaisants.

Comprimer les images

Pour comprimer les images, j’utilise depuis longtemps l’extension gratuite « Smush » et même maintenant l’extension payante (abonnement annuel wpmudev) « Smush Pro » qui apporte quelques avantages supplémentaires.

Autoriser la compression

Sur un serveur Infomaniak, il suffit d’activer la compression des fichiers (cf FAQ Infomaniak).

Evidemment, celà ne comprime pas les fichiers provenant d’autres sources, tels que https://s3.amazonaws.com/…ownloads.mailchimp.com/js/mc-validate.js, que mon site Parcours Performance charge systématiquement.

L’amélioration est significative puisque l’outil de test http://www.whatsmyip.org/http-compression-test/ m’indique que la page d’accueil de Parcours Performance faisait 57.9 KB, en fait maintenant 14.8 KB, soit une amélioration de 74.5% !

Activer le module Google Page Speed

Sur Infomaniak, il suffit également d’activer ce module (cf FAQ 1341 d’Infomaniak). PageSpeed Tools est un module proposé par Google qui permet d’optimiser la performance d’un site côté serveur en fonction de bonnes pratiques recommandées par le moteur de recherche.  Sur d’autres hébergements, il faudra voir cette page de Google et faire les réglages à la main si c’est possible.

Activation et réglage de Hummingbird Pro

Avec l’abonnement annuel wpmudev, j’ai accès à de nombreuses extensions, que je peux installer sur autant de sites que je veux. Dans le cadre de l’amélioration de la performance de mon site Parcours Performance, j’ai activé et réglé Hummingbird Pro. Il en existe une version gratuite dans le dépôt d’extensions WordPress. Ici je décris ce que j’ai fait avec la version Pro.

A l’activation de Hummingbird Pro, j’ai réalisé un test du site. La note est 68/100. J’ai réalisé les opérations suivantes :

  • leverage browser caching : l’extension propose de régler le cache (set expiry ) à 8 jours et d’aller mettre l’instruction correspondante dans le .htaccess.
  • remove render blocking ressources : Hummingbird liste 10 fichiers javascript et 14 fichiers css qui pourraient être chargés après l’apparition du contenu « au dessus de la ligne de flottaison ». Ensuite, il propose « configure script deferring » : on arrive alors dans un menu de « minification », qui permet pour chaque fichier javascript ou css de définir l’option de minification (création d’un fichier de taille réduite), et aussi de dire si le fichier doit être chargé dans le header (donc avant la « ligne de flottaison » de la page) ou le footer. J’ai tout « minifié », sauf le css de font Awesome, chargé de l’extérieur, mais j’ai laissé les fichiers se charger dans le header car il faut que je fasse des essais avant de décider que faire.
  • « Host my files on the WPMU DEV CDN » : wpmudev stocke mes fichiers sur un serveur rapide externe.

La note est du test d’Hummingbird est maintenant à 75/100, avec des améliorations à apporter à

  •  Improve server response time
  • Enable compression : Compressing https://s3.amazonaws.com/downloads.mailchimp.com/js/mc-validate.js could save 92.2KiB (66% reduction)
  •  Remove render blocking resources

Et maintenant ?

Je suis plutôt contente du résultat, ou du rapport temps passé / amélioration. Mais il va falloir que j’aille regarder comment faire encore mieux.

Dans un second article de cette série, , je vais réaliser toutes les opérations précédentes pour ce site, knowledge.parcours-performance.com et mesurer systématiquement les gains avec les trois outils de test cités en introduction.

Il me reste, selon PageSpeed Insights, à améliorer les critères suivants :

  • Éliminer les codes JavaScript et CSS qui bloquent l’affichage du contenu au-dessus de la ligne de flottaison : Votre page contient 11 ressources de script et 13 ressources CSS qui bloquent l’affichage de votre page, et donc le retardent. Il faut que je teste ce qui se passe pour chacun des 24 fichiers si, via Hummingbird, je demande à ce qu’ils soient chargés dans le footer…
  • Autoriser la compression : Autorisez la compression des ressources suivantes afin de réduire le volume de données transférées de 92,2 Ko (réduction de 66 %). La ressource concernée est https://s3.amazonaws.com/…ownloads.mailchimp.com/js/mc-validate.js qui n’est pas compressée.
  • Réduire le temps de réponse du serveur : Lors de notre test, votre serveur a répondu en 0,76 secondes.
  • Exploiter la mise en cache du navigateur : Si vous définissez une date d’expiration ou une durée de validité maximale pour les ressources statiques dans les en-têtes HTTP, vous indiquez au navigateur d’aller chercher les ressources déjà téléchargées sur le disque local plutôt que sur le réseau. Les ressources concernées sont https://s3.amazonaws.com/…ownloads.mailchimp.com/js/mc-validate.js (délai d’expiration non spécifié) et https://www.google-analytics.com/analytics.js (2 heures)

Je pense qu’il faut que je voies aussi les éléments suivants :

  •  Pour les mobiles, activer le mode « AMP ».
  • voir l’impact de la version MySQL (cf statistiques WordPress) sur la vitesse et la sécurité : il faut peut-être que je passe en version 10.x (je suis actuellement en version 5.6.35).

Adapter le thème Twenty Seventeen

Adapter le thème Twenty Seventeen

Dans l’article précédent de cette série , nous avons vu comment créer un thème enfant pour le thème Twenty Seventeen de WordPress et créer des modèles de page. Aujourd’hui, nous allons voir comment modifier les caractéristiques de l’image d’en-tête du thème et ajouter des sections à la page d’accueil.
Pour réaliser ces modifications, je me suis beaucoup inspirée de cet excellent article, sur Kinsta.com : A Developer’s Introduction to the Twenty Seventeen Theme.

Modifier les caractéristiques de l’image d’en-tête

Le thème Twenty Seventeen utilise une image de 2000 px de large, 1200 de haut. Je préfère une image moins haute, pour voir le contenu de la page sans avoir à utiliser la barre de défilement dès le début.

Je veux régler la hauteur de l’image à 350 px et utiliser par défaut une autre image. Et il faudra modifier la feuille de style pour supprimer le réglage qui met l’image à 100% de la hauteur d’écran.

Dans functions.php du thème enfant, ajouter :

add_filter( 'twentyseventeen_custom_header_args', 'al17_custom_header_args' );

function al17_custom_header_args( $args ) {
   // source https://kinsta.com/blog/twenty-seventeen-theme/
   $args['default-image'] = get_theme_file_uri( '/images/al_domotic-2000x350.png' );
   $args['height'] = 350 ;
   return $args;
}

J’ai ainsi défini une nouvelle image par défaut et réglé la hauteur des images à 350 px.

Dans le répertoire /images/ du thème enfant, ajouter l’image (qui doit faire 2000 x 350 px au lieu de ce qui est défini par le thème twentyseventeen (2000 x 1200 px)

 

Ensuite, on va dans « personnaliser » le thème et on sélectionne la nouvelle image suggérée. Cependant, elle ne s’affiche pas correctement à ce stade, puisque des règles de style l’interdisent.

Je modifie donc style.css du thème enfant

.has-header-image .custom-header-media img {
   height: 350px ;
   object-fit: none;
   min-height: 0;
}

@media screen and (min-width: 48em) {

   .twentyseventeen-front-page.has-header-image .custom-header-media {
           max-height: 550px;
   }
}

On notera que je n’ai pas modifié le style pour les petits écrans. Je verrai ça plus tard.

Maintenant, l’image d’en-tête s’affiche comme je le voulais :

Changer la taille d'image d'en-tête du thème Twenty Seventeen

 

Modifier le nombre de sections de la page d’accueil

C’est très simple à réaliser, il suffit d’ajouter cette ligne dans functions.php du thème enfant :

add_filter( 'twentyseventeen_front_page_sections', function(){ return 6; } );

Et maintenant, au lieu de 4 sections paramétrables dans le menu « personnaliser », on en a 6 :

Ajouter des sections à la page d'accueil (thème Twenty Seventeen)

Autres modifications

Si je veux avoir une page d’accueil défilante, je m’inspirerai de l’article cité en introduction et de ces deux articles de wpmudev.com :

Et maintenant ?

Je vais utiliser ce thème enfant pour construire un tableau de bord domotique pour ma maison (voir la série d’article ).