Bonjour !
 
J'ai construit un site Wordpress, sur la base du thème Astra, avec Elementor (+quelques modifications personnalisées du CSS via Astra), en mode "one page", hébergé chez o2switch. Il s'affiche à une vitesse convenable, néanmoins les sites de test de performance me donnent une mauvaise note, jusqu'à seulement 60% pour Google (pire sur mobile 12%!), ce qui me fait craindre pour le référencement.
 
Voici l'adresse : https://hesteau-avocat.fr
 
Bizarrement, selon PageSpeedTest, ce sont les Google CDN / Maps / Fonts qui me font perdre beaucoup de secondes. À part ça, Google m'encourage à améliorer mes feuilles de style CSS et le Javascript. Via un inspecteur web, on observe que j'en ai beaucoup... Je note aussi que certaines feuilles de style sont des "min" alors que j'ai retiré mes plugins de cache/minification (résultats décevants ou bugs). J'observe enfin que j'ai des feuilles de style en doublon.
 
=> Serait-il utile de nettoyer et/ou fusionner mes multiples feuilles de style CSS ? Si oui, comment (je suis autodidacte...) ?
=> Quant au Javascript, auquel je ne connais absolument rien, dois-je y toucher d'une quelconque manière ?
=> Voyez-vous des faiblesses ou erreurs importantes dans la construction du site, qui nuiraient à la performance ?
 
Merci beaucoup  

Plus de 5 Mo de fichiers à charger sur la page d'accueil et ça prend plus de 6s alors que je suis fibré, c'est clair qu'il y a un pb avec ton site
 
Tu mets tout sur une page, c'est pas du tout une bonne idée. Ceux qui vont consulter ton site avec un mobile vont te maudire. Tu peux soit faire du chargement à la demande des différentes sections en fonction de la position du scroll vertical (nécessite du js) soit une page dédié à chaque section.
 
Essaye aussi d'optimiser la taille de tes images pour en diminuer le poids.
 
Edit : ex, ton image de fond avec des triangles qui se répète. Faits une image plus petite que tu vas dupliquer sur x et éventuellement y avec le css.

Exemple tout con : ton logo en SVG fait 429 ko, en passant un coup de SVGO dessus il passe à 16ko, j'ai divisé son poids par 26 sans perte de qualité.
il ya 4 appels à recaptcha_en.js, il doit y avoir une mauvaise intégration de celui-ci.

Merci à tous les deux    
 
Je viens de compresser le logo comme conseillé (17ko) et supprimé carrément le reCaptcha (c'était pour le formulaire de contact or WPforms inclut un pot de miel donc ça devrait suffire) mais il faudrait que je vérifie qu'il n'y a plus de requêtes : je peux voir ça où ?
 
Les autres images sont optimisées avec Imagify. Le background de triangles reste un peu lourd, mais ce n'est pas une simple multiplication des mêmes triangles. Donc soit je laisse cette petite lourdeur, soit je sacrifie l'esthétique : j'y réfléchis encore.
 
Le design "one page", j'y tiens (pour le moment) : c'est assez courant pour un site vitrine, dans les codes de navigation mobile/réseaux sociaux, et je n'ai pas énormément de contenu donc je garde l'espoir d'optimiser tout ça.
 
Vous n'avez rien dit sur les multiples feuilles de style CSS et le Javascript : le problème n'est pas là ?
 
J'envisage de copier-coller le contenu de mes différentes feuilles dans un même fichier. Je ne sais pas si je dois passer par un thème enfant, que je n'avais pas créé jusqu'ici car je n'avais pas touché aux fichiers directement, j'ai travaillé uniquement avec Elementor.

Ton vient entre-autre de tout sur une page. Perso, je trouve ça horrible et pas ergonomique du tout. Ce concept sur 1 page ça se fait couplet au chargement dynamique ou infinite scroll

mets aussi en place du lazyloading pour les images, ne charger les images que lorsqu'elles apparaissent dans le viewport

Si aussi, mais à la main c'est compliqué à optimiser si ce n'est pas ton métier.
Tu pourrais donc employer un plugin comme https://wordpress.org/plugins/shins-pageload-magic/
Fais des recherches dans les plugins, certains sont payant aussi.
Regarde si ton score est meilleur et garde celui qui fonctionne le mieux.
 

+1 pour le fait que tout sur une seule page c'est horrible (mais à la mode). Et rajouter du lazy-loading c'est rajouter du JS non? Encore pire, encore un site qui ne tournera pas sans...

Les sites full js, c'est une vraie galère pour l'accessibilité du web, en particulier aux mal-voyants.
J'ai l'impression que peu de web dev sont sensibilisé à cette question dans leur formation. Ca représente pourtant entre 10 et 15% de la pop française. C'est donc pas négligeable du tout en terme de business.

heu un lecteur d'écran se base sur le DOM, donc si le site est fullJS ça peut passer, c'est le changement de page ou autre qui peut être vraiment chiant

[HS]J'aimerai bien avoir des précisions sur ces chiffres, car à moins de comptabiliser les personnes qui portent des dispositifs de correction de vue (lunettes ou lentilles) je ne vois pas comment on peut atteindre un nombre aussi élevé. Et évidemment ça n'a pas de sens d'utiliser cette statistique si elle compte ces personnes là puisqu'elles disposent déjà d'une solution rendant caduque le problème de l'utilisation du JS.
Après je ne dis pas qu'il ne faut pas faire d'effort, c'est juste que le chiffre me semble trompeur.[/HS]

Ce qui pose pb, c'est le changement de contenu une fois la page chargée. NVDA, l'un des lecteurs d'écrans les plus répandus et gratuit, ne sait pas gérer.
 
L'un des membres de l'école de ma fille est aveugle à 85-90%. Elle me raconte de temps en temps les pbs qu'elle rencontre en surfant sur des sites. Elle me disait notamment que beaucoup de sites de e-commerces ne sont pas adaptés pour elle. A un moment donné, dans le processus d'achat, y'a un truc qui fait qu'elle ne peut pas aller au bout seule.

Autant pour moi, j'ai mélangé la stat du handicap visuel avec l'ensemble des handicapés rencontrant des pbs pour accéder aux sites web (et dans ce cas, ma stats était sous-estimée) :  
https://ircf.fr/actualites/accessib [...] -internet/
https://www.aveuglesdefrance.org/qu [...] e-visuelle
 
Le handicap visuel c'est un peu moins de 3% de la pop en France (1.7 millions), désolé.

Le lazy load pour les image actuellement c'est ajouter un attribut loading="lazy"
Et une solution en JS seulement pour les navigateur qui ne supportent pas cet attribut
 
On peut noter que c'est implémenté par défaut dans Wordpress 5-4 https://www.searchenginejournal.com [...] ng/346006/

Je vais encore dégonfler tes chiffres.  
 
18% de la population (en France) souffre d'un handicape, ça ne veut pas dire que le JS rend inaccessible les sites à 18% de la population. Suffit de prendre l'exemple d'un cul-jack, il est handicapé, mais l'utilisation du JS ne va rien changer à son expérience sur le site par rapport à un valide.
Pour les problèmes visuels, de même, le chiffre le plus représentatif est probablement plutôt celui des aveugles [207 000] + les malvoyants moyens (incapacité visuelle sévère : en vision de loin, ils ne peuvent distinguer un visage à 4 mètres ; en vision de près, la lecture est impossible) [932 000] d'après ton lien.
 
Mais ça n'empêche en rien de les prendre en compte, ce qui serait le plus efficace c'est que les outils (que je ne connais absolument pas) permettant de faciliter la navigation pour les situations d'handicape puissent surtout s'adapter au JS et que seules les rares cas ne pouvant être solutionnés fassent l'objet d'une communication. Car comme dit par Gatsu, la modification du DOM par le JS ne donne que du DOM qui reste interprétable de la même manière que le DOM précédant.
 

Merci, je note, j'en étais resté à la solution JS.

Le pb du DOM modifié après le chargement de la page, c'est que ça oblige la personne à relire toute la page.
En effet, le CSS permettant de changer l'ordre d'affichage d'une info dans la page par rapport à sa position dans le DOM fait que un lecteur d'écran ne va pas savoir comment intégrer le nouveau contenu à ce que l'utilisateur a déjà lu. Après, je ne suis pas un spécialiste de ce genre d'outil mais je l'ai installé pour tester les évols que j'ai ait sur mon outil Canteen Calandreta (la personne aveugle que j'évoquais l'utilise).
 
Mais essaye NVDA et fermez les yeux puis allez sur vos sites favoris. Vous allez rapidement vous rendre compte à quel point c'est difficile. C'est très instructif ce genre de "vit ma vie"

Dans ma dernière phrase, je veux juste dire que le JS n'est pas forcément le bon coupable. Le JS fait parti maintenant de l'environnement, or il y a deux solutions pour palier à un handicape :
- modifier l'environnement,
- ou, utiliser des outils permettant d'évoluer dans l'environnement.

Que faut-il préférer ? Je n'ai personnellement pas d'avis tranché, et j'adopte cette vision au sens large des termes que j'ai utilisé. L'environnement est ce qu'il est, mais qu'on soit handicapé ou non on le façonne pour répondre à nos besoins donc pourquoi ne pas le faire pour un handicape ? D'un autre côté, l'environnement n'est pas la cause de l'handicape, pourquoi devrait-il s'y adapter ? Si on élimine l'aspect humain, la seconde réponse semble évidente, mais en même temps si on retire l'humain on n'a pas plus de handicape...
Bref, le problème ne me semble pas aussi simple que c'est la faute du JS.

Pendant ce temps les amis, je viens de refaire une test comme ça, sur PageSpeed Insights, et j'ai ma pire note de tous les temps sur mobile : 8 !  
 
Dans les réjouissances :
Indice de vitesse
12,2 s
Largest Contentful Paint
12,8 s
Délai avant interactivité
23,4 s
Total Blocking Time
11 080 ms
 
Dans le diagnostic :
 
Réduisez le travail du thread principal 38,5 s (!!)
   Script Evaluation
   14 962 ms
   Rendering
   8 996 ms
   Style & Layout
   7 580 ms
   Other
   4 674 ms
   Parse HTML & CSS
   1 092 ms
 
One page ou pas, j'en déduis qu'il y a forcément d'énormes coquilles à nettoyer dans mon site. Votre aide est toujours le bienvenu

Ta page pourrait être découpée en 5 pages. Ca divisera globalement le temps de chargement par 5.
Ligne 53 : <style id='astra-theme-css-inline-css'>
T'as plein de css dans ta page. Du coup, ce css est rechargé à chaque fois car pas mis en cache.
 
Y'a plein de div vide ou emboîtés les uns dans les autres n'importe comment (L519 à L722).
 
Bref, du code html bien merdique On a l'impression que ça a été fait avec un outil wysiwyg comme le faisait dreamweaver ou frontpage. Du coup, que les perfs soient moisies, y'a rien d'étonnant.
 
J'ai noté que ta page était passée de 5 mo à 3.3 Mo : c'est mieux, 3.2s à charger.

Je termine sur ce HS (pardon à l'auteur de ce topic) : à mon sens (mais je ne suis pas le seul à le penser, Raphaël Goëtter qui fait le site Alsacreation est sur une ligne similaire d'après son livre sur le CSS 2.1), on construit un site web avec le moins de HTML possible et en utilisant les balises uniquement en fonction de leur sémantique. L'idée est que même sans CSS, en voyant un site avec juste le HTML, on repère les différentes sections, les titres et les infos.
 
Ensuite, on ajoute le CSS pour un rendu visuel agréable et utilisable.
 
A ce stade, les principales fonctions du site doivent être opérationnelles (formulaires, tableaux paginés...) avec juste le langage côté serveur.
 
Enfin, on ajoute du JS pour améliorer l'ergonomie et l'expérience utilisateur. En faisant ça plus qq petites choses à faire attention, tu as un site web accessible au plus grand nombre, au moins de niveau AA.
Et ça permet encore de pouvoir bookmarker des pages d'un site. Sur certains sites full js, les bookmarks ne amrchent plus car tu te retrouves en fait sur la page d'accueil, la partie à laquelle tu es arrivé résultat d'une succession d'actions gérées par le JS, donc pas bookmarkable

Le livre CSS 2.1 de raphael Goetter date de 2003, depuis 2003 les choses ont un poil (gros poil, TRES TRES GROS POIL) changées

Mais dans les lignées directrices, tu as globalement raison, et j'aimerai pouvoir continuer dans cette voix, mais force est de constater que react et consorts ont pris le dessus

Oui, bien sûr, les choses avancent vite en informatique mais je dois avouer que ce n'est pas toujours vers le mieux Après, je ne vais pas faire mon vieux con avec le "c'était mieux avant" (clairement pas, ceux qui ont connu le css 2 et la joie des balises <layer> de NS vs <div> de MS savent de quoi je parle   )
J'ai eu un stagiaire l'an dernier : pour me faire un menu vraiment simple avec une petite icône à gauche de chaque item, vas-y que je te mets Font Awesome. Même pas eu l'idée de mettre une <img /> qui va se mettre ensuite dans le cache et qui évite une dépendance à un framework Et c'était tout comme ça : pour juste pouvoir faire $(), vas-y que je te mets jQuery. Non, document.getElementById(), c'était trop compliqué... Et je te parle même pas de la technique du masquage de bits pour coder des options et savoir si telle ou telle est activée : carrément même pas vu en cours.
 
A force d'empiler les couches de libs/frameworks en tout genre pour faciliter la vie aux dév, ils ne touchent parfois plus terre et connaissent à peine les fonctions de base d'un langage. Purée, on est loin de l'époque des démomakers qui cherchaient à optimiser chaque octet.
 
Mais certaines technos ou outils sont vraiment bien. Le Css 3 a apporté pleins de trucs sympas, comme le HTML5 par ex.

Merci d'avoir regardé ça de près, c'est ce dont j'ai besoin.
 
Question de débutant sans doute : comment je retrouve les numéros de ligne dont tu parles ?
 

 
"Plein" de feuilles de style (d'où ma question sur leur "fusion" ) ou plein d'appels aux feuilles de style (ça je vois pas comment le changer) ?
 

 
C'est fait avec Elementor. Est-ce que je l'ai "mal" utilisé en mettant des sous-sections dans des colonnes par exemple, ou est-ce qu'Elementor de base ne fait pas du propre, ou est-ce que des plugins ont pu mettre le bazar ? En tout cas je suis limité sur ce point, je vais pas toucher au code Html puisqu'il est géré par Elementor (si?).

Quand tu regardes ton site avec ton navigateur web (ex : FF), tu fias afficher le code source (avec FF, ctrl+u) : normalement, t'as les n° de ligne mais ça, c'est le rendu html/css, donc pas toujours facile de retrouver d'où ça vient avec les outils qui ont généré ça (ici, Elementor).
 
Elementor est un outil wysiwyg comme ceux que je citais : il a donc les mêmes défauts. Notamment un : il est probable que durant la création, tu aies fait des essais, retour arrière... pour arriver au résultat final. Certaines manips ont peut-être laissé du code html/css inutile.
 
Le css qui pose souci n'est justement pas dans un fichier alors qu'il le devrait. Le fait d'avoir plusieurs fichiers css n'est pas forcément un pb (bon après, il n'en faut pas 50 non plus). Mais avoir des balises <style> dans le html, pour moi, ça ne devrait pas (tout comme le js intrusif).
 
Un bon site web, c'est des pages qui ne contiennent que du html avec des id et des attributs "class" pour permettre au css et au js de faire le taf et du css dans des fichiers css et du js dans des fichiers js appelés à partir des pages html via les balises <link> et <script> dans le <head> et pis c'est tout

Un bon site certainement et je respecte vraiment le métier de développeur. Maintenant en tant qu'amateur, si je pouvais faire un site "correct", ça m'irait déjà
 

 
Effectivement. Maintenant que j'ai mon rendu final souhaité, je pourrais éventuellement créer une nouvelle page, et tout refaire avec Elementor mais sans allers-retours. Je devrais y parvenir en quelques heures. Ca vaudrait le coup ?

C'est à tester. Avec ce genre de truc, difficile à dire.
A leur décharge, arriver à créer un outil wyiswyg qui permet de faire n'importe quelle mise en page à la souris tout en générant du code html et css propre comme un bon web dév, c'est très chaud

Je viens juste de créer une page et de mettre seulement une image dedans, avec Elementor. Note du test de vitesse google : 60 sur mobile, 86 sur ordinateur. C'est bien, mais je ne suis même pas dans le vert, alors que je n'ai quasiment aucun contenu...
 
Si un utilisateur d'Elementor passe ici, je serais curieux de savoir si c'est habituel avec ce page builder d'avoir une vitesse max aussi limitée. Si oui, pas la peine que je recommence toute ma page. Si non, il faut peut-être que je réinstalle Elementor, mais est-ce que je retrouverai mon site "assaini", ou tel quel, ou pas du tout ?

Le test que tu devrait faire c'est de désactiver tous les plugin et faire un page avec Gutenberg (le page builder par défaut de wordpress) et un template de base Wordpress (le dernier en date doit être Twenty Twenty) pour voir ce que Wordpress sur ton hébergement donne en terme de perf, si tu as des scores toujours aussi mauvais (alors que Wordpress "de base" fait quand même de gros efforts en terme d’optimisation) c'est que ton hébergement a sans doute une part de responsabilité...
 
Edit : Et non, supprimer et réinstaller un plug-in ne changes sans doutes pas ton contenu (ne l'assainira pas non plus).
A part sans doutes certains plug-in du genre traductions qui modifie profondément le fonctionnement interne...

Désolé pour le HS, mais si tu t'intéresses au sujet, y'a un très bon topic pour ça

https://forum.hardware.fr/forum2.ph [...] w=0&nojs=0

 
J'ai créé une page avec l'outil Wordpress, et retiré les choses progressivement. Voilà les notes sur mobile / ordinateur :
 
- De base (avec plugins et thème Astra) : 76 / 92 => C'est un peu mieux que ma page de test créée avec Elementor.
- Avec plugins et thème Twenty Twenty : 81 / 90 => Astra me fait perdre un peu en mobile, mais ça reste similaire.
- Sans plugins et thème Twenty Twenty : 98 / 100 => Les plugins pèsent davantage, mon hébergement est bon.
 
Pour finir, j'ai remis juste Elementor et le thème Astra, et re-testé mon vrai site : j'obtiens 24 / 81. À croire donc qu'Elementor à lui seul fait s'écrouler ma note mobile, tandis que mes autres plugins font chuter la note ordinateur.

Du coups poses toi les questions de ton besoin, que permet de faire elementator qui tu ne peux pas faire avec Gutenberg ?
 
Ce genre de plugin sois disant Wysiwig n’hésites pas à mettre du style inline (ou une grosse zone de règles css en dur dans la page avec des ids de partout), et génères sont contenu à grand coup d'expression régulière...
 
Sans compte que dans quelque temps il n'est pas exclus que le plug ne soit plus maintenus un jour, mon conseille quand on bosses avec Wordpress c'est d'utiliser le moins de plug possible ! ^^

Oui je commence à y réfléchir Je vais déjà dupliquer la page et voir ce que l'éditeur Wordpress me permet de faire pour retrouver le même rendu.
 
En parallèle néanmoins : existe-t-il un outil de conversion Elementor -> Gutenberg ?

Quand je le dis que les outils wysiwyg, c'est de la merde

Je connais ce topic, of course Marrant qu'il remonte pile le jour où tu m'en reparles.    
Je parlais des démomakers pour faire une comparaison d'état d'esprit avec les dévs actuels qui ne sont pas confrontés aux mêmes pbs : puissance et espace de stockage. Encore qu'avec le big data, ces pbs reviennent : qui sait, on refera peut-être appel aux compétences des démomakers ?  

Des nouvelles : toujours avec Elementor mais à grands coups d'optimisation (compression d'images, suppression de deux plugins, CDN...), j'obtiens maintenant de très bonnes notes sur GTMetrix (92-94%), même si le chargement complet est encore un peu long.
 
PageSpeed Insights ne fonctionne plus (je crois que c'est depuis que j'ai mis Cloudflare), mais j'ai trouvé plein d'autres outils en ligne de test de performance MOBILE et là, il y a encore un peu de boulot. Je continue !

Laisse tomber ton one page et Elementor, tu vas voir que ta note va bien remonter. Mais comme suggéré, vérifier qu'avec un site très léger chez ton hébergeur a une bonne note.

J'ai bien compris. D'ailleurs pour les débutants comme moi qui passeraient par là et s'interrogeraient sur Elementor (alors qu'on en dit beaucoup de bien), voilà un article (long) intéressant qui tire à boulets rouges : http://pagepipe.com/how-elementor- [...] age-speed/
 
Perso, j'attends d'aller au bout de ma piste "optimisation" avant de quitter ou non Elementor.

Selon Cloudflare, mon site se charge désormais totalement en 2,7 secondes. J'ai un excellent score GTmetrix (99%/97%) et un score Google acceptable (89%) sur ordinateur. En revanche, je peine toujours sur le mobile (mais pourquoi est-ce si différent ?!).
 
Sur mobile, le principal problème semble être le chargement de 4 fichiers CSS qui "bloque le rendu" bien davantage que sur ordinateur. J'ai tenté l'option "mettre en ligne et différer le CSS" du plugin Autoptimize, mais cela dégrade ma note sur les deux supports, en allongeant le temps de réponse du serveur.
 
Vous comprenez pourquoi ? Et j'en reviens à ma question de base : y a-t-il un moyen de simplifier et/ou rassembler ces CSS, sans changer de configuration (Wordpress/Elementor/Autoptimize) ?

J'en doute : chaque plugin crée son ou ses fichiers CSS.
Sur mobile, on considère que plus il y a de fichiers à récupérer, plus c'est pénalisant car le ping en 4G est bien plus important que sur fibre/ADSL. Donc, chaque requête va prendre plus de temps. Au final, pour une même quantité de données, à débit identique, le mobile mettra plus de temps qu'un PC à charger le site.
Du reste, c'est pas pour rien que beaucoup de sites font maintenant une version mobile, très différente. Bien entendu, c'est pour prendre en compte la taille de l'écran (bien que désormais, avec le responsive design, on sait traiter ce cas) et l'ergonomie qui est différente mais on constate que l'IHM est souvent plus épurée.

Merci je comprends mieux
 
Je suis en train de tester W3 Total Cache à la place d'Autoptimize. Je constate qu'il élimine plus efficacement le rendu bloquant. En revanche ma note mobile n'est pas meilleure car maintenant c'est "le travail du thread principal" qui est trop long (+3,6s!). Ça continue ^^'