Pour madame michu et tonton rené Wordpress c’est propre je le reconnais volonté. Mais pour les serveurs c’est une cata en utilisation de ressources…
Le constat : 90% des sites sous Wordpress que j’héberge sont des sites static/vitrine ou quasi static. Et quand c’est « quasi static » c’est le formulaire de contact quoi… Donc
En gros l’idée :
Laisser les wordpress pour l’édition en ligne de madame michu sur www.lesiteatata.fr
Générer du code HTML à partir des wordpress (wget, HTTrack, https://wp2static.com, peut importe) et servir ce code au visiteur… Ces pages HTML pourrait être (re)générer plus ou moins automatiquement et serait sur static.lesiteatata.fr
Varnish ne fait pas de HTTPS donc tu devrais coller un fontend à lui. J’ai abandonné Varnish pour Nginx car je ne sais plus de développement avec de l’ESI (mise en cache partielle d’une page).
Son mon serveur, j’ai un apache qui génère aucun cache car j’ai un frontend nginx qui le fait. Tu peux facilement créer un cache des pages/asssets avec Nginx via des règles sur URI requêtée.
Hello,
De mon coté j’explore GatsbyJs , qui propose de faire des sites statiques ReactJs, avec des websockets et cache hors ligne.
Donc ya l’avantage du statique, et du websocket qui en theorie limite les aller-retours réseau car tout est dans le cache local du navigateur.
Il dispose de nombreux plugins dont celui qui utilise Wordpress comme source de données.
Le site https://colibris-outilslibres.org utilise gatsby mais juste avec comme source des dossier avec du markdown cf. code source
Si, en fait tu peux dire au serviceWorker de garder en cache tes assets et dans ce cas, après la première connexion, ya plus d’appel réseau, le service Worker prend le relais, cf. https://developer.mozilla.org/en-US/docs/Web/API/Cache
Le plugin WordPress WP Supercache marche bien sinon pour charge des pages html statiques. Couplé à un Varnish, j’ai pas encore senti le besoin d’aller plus loin sur l’optimisation.
Ca fait plusieurs années que je veux faire pareil.
Je commence à toucher au but dans la réflexion.
Il y a 2 plugins WP pour statique et il semble qu’ils sont matures aussi.
En gros:
WP derrière un http auth connect id connecté à mon SSO.
Quand tu tapes cette URL, ça démarre les containers.
Apres tu te log avec le SSO et tes sur le WP.
Tu fais ce que tu as à faire. Tu cliques sur publish, et ça envoie le tout sur un object stone servit en statique.
Pour le formulaire de contact, tu le grep/sed vers un microservice générique, http POST to email quoi.
Et tout le monde devrait être content
Meme plus besoin update wp a la limite derrière le httpauth, bcp moins de chance de se faire pwned.
J’avais déjà fait a un client, mais c’était moins abouti, il était pas content ;)surtout les non techs qui devait update les post du wp (à base de virtualbox et de httptrack si je me souviens bien)
Oui il y a des plugins qui font ça bien, mais du coup il n’y a pas de notion de « transparence » (service du static à des moments, et sur certaines pages en servir une autre…)
Outch, c’est peut être exposer son mail… (il y a le mail en clair dans le code…)
Je me pose une question: Cela vaut-il vraiment le coup sur des sites très peu fréquentés ?
On rajoute en effet un peu de complexité, un peu plus de code, qui lui aussi va demander des ressources… donc à partir de quand y gagne-t-on vraiment ?
Ces caches sont en général plutôt conçus pour tenir de fortes charges et/ou améliorer les temps de réponse.
Whouah, je pense sincèrement que c’est sortir le tank pour flinguer une mouche.
HTTP propose déjà des mécanismes de cache coté client. Ça fonctionne pour tout les documents qu’un serveur web peut servir et ça permet aux gens de ne pas requêter inutilement le serveur. Ensuite, une cache géré via nginx/varnish en s’appuyant sur :
soit la gestion des entêtes HTTP renvoyées par le backend (apache via ou pas le CMS)
soit via des règles sur le routing de l’application (naïvement : tout sauf /wp-admin ou /contact)
Modulo l’invalidation du cache qui peut être tricky, le reste est vraiment pas complexe.
Ça évite de taper dans le code de Wordpress ou d’installer un anième plugin qui augmente la surface d’attaque. Ça veut aussi dire que si le Wordpress doit changer d’hébergement, ça pourra se faire sans question à se poser.
Ah, ca joue quand meme vachement. Avec le plugin je peux potentiellement heberger bien plus de sites avant de devoir augmenter les ressources. Pour moi c’est tout justifié. Bien sur il faut faire le tri dans les plugins et eviter justement les usines a gaz (Yoast, Jetpack, etc.), mais bon, un WordPress ‹ stock › il manque pas mal de choses que les plugins viennent combler.
Après sinon effectivement, ne pas utiliser WordPress si on cherche de la perf. Mais je pense qu’il y a peu de solutions aussi simple pour l’utilisateur non-technique, sinon il serait pas aussi populaire (bien que très imparfait).
derrière le httpauth, bcp moins de chance de se faire pwned.
