Contact Whatsapp

imaginez, créez. Un coup de main ?

Menu

Catégorie : Wordpress

  • Quel page builder WordPress choisir ?

    La promesse de « pages builder » comme Elementor, Divi et Gutenberg est alléchante : créer un site Internet sans toucher une ligne de code. Et cela fonctionne ! De nombreux sites sont réalisés avec ces constructeurs de page. A l’heure de réaliser votre site internet avec WordPress, vous vous demandez peut-être vers quelle solution vous tourner. Ce choix n’est pas anodin et peut impacter la performance et, au final, la visibilité de votre site – pour être plus précis, son positionnement dans un moteur de recherche. Mieux vaut le savoir avant de démarrer… Alors quel page Builder WordPress choisir ? On fait le point.

    Page builder WordPress
    Etat des lieux…

    Elementor et Divi sont les premiers page builders qui ont été publiés pour WordPress. Ces pionniers de la construction de page ont facilité la réalisation de sites internet à de nombreux graphistes et designers désireux de publier de beaux sites web « sans mettre les mains dans le cambouis ».

    Gutenberg est, comparativement, un nouveau venu. Ajouté au code source de WordPress par l’équipe de développement du CMS en fin d’année 2018, il fournit le même genre de fonctionnalités sans abonnement et progresse avec régularité. De nouveaux pages builders apparaissent depuis sa publication, comme Oxygen, Astra, Bricks et bien d’autres : ils ajoutent des fonctionnalités à l’éditeur Gutenberg pour mieux combler les besoins des utilisateurs.

    L’utilisation d’un constructeur de page s’impose ainsi comme une nouvelle façon de concevoir et réaliser son site internet. Il devient difficile de proposer autre chose à un utilisateur, cela revient à le priver de possibilités d’édition avancées faciles à prendre en main. Pourquoi ferait-on cela ?


    Alors oui, mais là…
    il n’y a pas un problème ?

    S’exclame le développeur Web devant le code source généré par ces outils

    Oui, il y a bien un petit soucis. Les pages builders nécessitent pour leur fonctionnement des ressources supplémentaires, et génèrent un code alourdi et complexe ; c’est particulièrement vrai pour Divi et Elementor. Quel impact ont-ils vraiment sur les performances de WordPress ? Cet impact est-il vraiment catastrophique au point de préférer se passer de ces outils ?

    Les comparatifs sur Internet sont nombreux, et les résultats sont globalement similaires… voyons-en quelques uns.


    Comparatifs
    Divi vs Elementor vs Gutenberg

    Un premier Benchmark très intéressant est celui réalisé par l’agence profileTree. Le comparatif est réalisé sur le même serveur, la configuration ne change donc pas d’un page builder wordpress à l’autre. Les résultats offrent un aperçu de l’utilisation des ressources serveurs et de la complexité du code produit :

    MetricDiviElementorGutenberg
    Temps de chargement*3.9s3.4s2.1s
    Nombre de requêtes à la base de donnée634728
    Consommation mémoire (par page)92Mo78Mo45Mo
    Temps de traitement par le CPU420ms340ms180ms
    Nbre d’éléments dans le DOM31024595

    * Avec une connexion 4G. Source

    D’autres Benchmark fournissent le même genre de résultats. Voici un autre exemple de mesure réalisée par un développeur qui s’est focalisé sur le temps de chargement, la vitesse et le score SEO :

    MesureDiviElementorGutenberg
    Chargement*3.2s2.8s1.5s
    TTFB#2.1s1.8s0.9s
    Score SEO 78/10085/10092/100

    * Temps de chargement – moyenne.
    #Time to first byte : le temps qu’il faut à un serveur pour envoyer le premier octet de données après qu’une requête a été faite par un navigateur. Source

    Résultats :

    Pas de mystère : les ajouts de fonctionnalités impliquent un code plus lourd, des ressources supplémentaires à télécharger, plus de requêtes à la base de donnée, et un score SEO moin bon. L’hébergeur Kinsta, qui a fait ses propres benchmarks, résume la situation:

    « Gutenberg a presque toujours fourni un score de performance plus élevé, une taille de page plus faible et un temps de chargement plus rapide, ainsi que moins de requêtes. » – Kinsta


    Conclusion

    Si les constructeurs de page ont leurs avantages, vous l’aurez compris en jetant un œil aux chiffres ci-dessus : se contenter des fonctionnalités du page builder par défaut de WordPress vous évitera d’alourdir votre site. Les constructeurs de page basés sur Gutenberg comme Oxygen peuvent eux aussi être impactés par un recul des performances, et nécessiteront le plus souvent un abonnement annuel pour être utilisé. Mais si vous avec besoin des fonctionnalités d’un page builder WordPress avancé, c’est sans doute vers ce type de constructeurs qu’il faudra vous tourner. A moins bien sûr que le score SEO de votre site ne vous émeuve pas plus que ça, et que vous ayez quelques euros supplémentaires à dépenser. Dans ce cas, testez Elementor, Divi et les autres, et choisissez celui qui vous plaît le plus !

    Un dernier mot : les bonnes performances de votre site ne dépendent pas uniquement du constructeur de page : des extensions nombreuses et lourdes, un cache mal réglé ou des éléments peu optimisés vous feront inexorablement perdre des places dans les résultats des moteurs de recherches. Alors si vous ciblez une bonne visibilité de votre site sur Internet, mieux vaut faire des choix judicieux dès le démarrage de votre projet : commencez par choisir le page builder WordPress qui ne plombera pas votre site web !


  • Créer son thème WordPress : thème « Classic » ou « block » ?

    Depuis plusieurs années déjà, WordPress prend une direction clairement décriée par de nombreux développeurs avec l’ajout de fonctionnalités de « pages builder » au cœur du CMS. Il faut dire que le succès de ces constructeurs de page – comme Divi et Elementor, pour ne citer que les plus connus – est tel que l’intégration de ce type d’outil au sein de WordPress ressemble à une évolution naturelle. Même si cela fait grincer des dents tous ceux qui n’ont pas du tout besoin d’une interface cliquable pour créer un site internet. Surtout quand cette interface impose des choix discutables en terme de performances et de séparation du contenu et du style.

    Code vs no-code
    Faire son site à l’ancienne

    Choisir de se débarrasser du page builder natif de WordPress (Gutenberg de son petit nom) peut donc se révéler très tentant, en particulier après avoir jeté un œil à la façon dont un thème WordPress de type « block » est organisé : avec son fichier de paramètres au format Json, ses commentaires HTML destinés à l’éditeur et ses options stockées dans la base… l’édition des thèmes WordPress ne s’est pas simplifiée pour les développeurs et les intégrateurs. On peut aussi être très vite agacé par le nombre de clics et d’options à rechercher puis à modifier avec sa souris, alors qu’on pourrait faire ces modifications sur une feuille de style CSS tellement plus vite…

    LIRE LA SUITE

  • Changer le préfixe des tables de la base de donnée WordPress

    A l’installation de WordPress, il est tentant (et sans doute courant) de conserver le préfixe de base de donnée proposé par défaut : wp_ Sans doute qu’en tant qu’utilisateur lambda de WordPress, on ne voit pas tellement d’intérêt à changer cette valeur, qui plus est proposée par le script d’installation : la laisser en l’état ne change rien à l’utilisation du CMS et ne posera aucun problème particulier à l’usage.

    A quoi ça sert ?

    Un préfixe ajouté aux tables d’une base de donnée sert avant tout à organiser les données. Avec un préfixe, on peut en un coup d’œil identifier dans une base les tables gérées par WordPress (par exemple) ; et quoi de mieux que wp_ pour identifier les tables d’un site WordPress ? On pourra ainsi, dans une même base de donnée, créer de nouvelles tables qu’on affublera d’un préfixe différent et qu’on réservera à un autre usage. Dit simplement, le préfixe est une bonne pratique avant tout pour ranger ses données, même s’il est aussi recommandé pour d’autres raisons. Alors où est le problème, et pourquoi modifier cette valeur ?

    LIRE LA SUITE

  • Les 10 commandements de la sécurité sur WordPress

    #1 Des sauvegardes quotidiennes tu feras.

    Backup, backup et backup : c’est l’ultime mesure de sécurité que tout site et application sur le Web doit mettre en œuvre. Si ça tourne mal, la sauvegarde de la veille fera l’affaire.

    #2 Ton WordPress tu garderas à jour.

    Le CMS, les extensions et les thèmes doivent systématiquement être mis à jour au fur et à mesure de la publication de nouvelles versions. C’est la seule manière d’obtenir les correctifs de sécurité indispensables.

    #3 Seules les extensions vraiment indispensables tu installeras.

    Limiter le nombre d’extensions installées réduit le risque de se retrouver avec un script vulnérable. Accessoirement, cela limite aussi la lourdeur du site, facilite sa gestion, évite l’incompatibilité possible entre différentes extensions… bref, sur WordPress : less is more.

    #4 Ton identifiant et ton mot de passe tu blinderas.

    Non, l’identifiant « toto » avec le mot de passe « 123456 » n’est pas une bonne idée. Votre prénom, date de naissance et d’autres informations personnelles sont aussi sans doute déjà sur Internet. Un identifiant complexe (non publique) associé à un mot de passe encore plus complexe (12 caractères variés minimum!) assurera l’essentiel. Pour un accès davantage sécurisé, l’authentification à 2 facteurs (2FA) peut être mise en place, mais il faudra installer une extension supplémentaire.

    Lire la suite