Rafraîchissement d'une page web

Bonjour,
la balise meta refresh étant obsolète et déconseillée en SEO, quels sont les bonnes pratiques à ce jour pour rafraîchir une page web (côté serveur). Une alternative à une redirection 301.
Sur certains de mes sites, tout est en cache sur le serveur, excepté le css. Je le change assez souvent, soit pour effectuer des modifications soit pour expérimenter. À chaque fois, les tests Lighthouse le signalent. Plus gênant, les visiteurs peuvent aussi lire une page décalée parce que j'ai modifié le css.
Comment font les gros sites des médias qui changent les textes et les images chaque jour ?
Merci, mais passez Noël avant de répondre, j'ai le temps.

salut
a chaque modif du css je change son nom n°, ex css623 624 etc

La solution de gcyrillus, avec le point d'interrogation, est facile à mettre en place (un minuscule script ajoutant une valeur timestamp au lien de la ressource) mais empêche la mise en cache par le navigateur. La solution proposée par drphilgood est meilleure, car ne contrarie pas la mise en cache, mais nécessite plus d'effort de développement (renommage du fichier source lié à un timestamp, effacement du fichier précédent, réactualisation du lien vers la source...).

Ah oui... alors, quand je parlais de scripts, je pensais à quelque chose côté serveur (PHP ou autre) et cela pour les deux solutions que j'ai énumérées plus haut : une fois le résultat généré le script n'a pas besoin d'être revu et revu.

Côté client, tant que l'on est dans une période de développement, pourquoi pas (le script n'a pas besoin d'être référencé, le SEO se moque du CSS, et même du JavaScript... en principe ***), mais dans ce cas j'opterais pour un gestionnaire d'événement lié à DOMContentLoaded en lieu et place du setTimeout. De toute façon, même le contenu du script ne va pas du tout : il ne faut pas faire de direction 301. À la place on pourrait cibler le lien du CSS et ajouter le fameux "?" et un timestamp.

___
*** D'aucuns disent que certains moteurs de recherche pourraient faire attention à l'accessibilité, tel qu'un texte blanc sur du fond blanc, ou encore les display:none, mais je demande à voir.
Modifié par Olivier C (26 Dec 2024 - 15:56)

Ah oui au fait, le code :

document.addEventListener('DOMContentLoaded', () => {
  const cssLink = document.querySelector('link[rel="stylesheet"]'); // cible à modifier éventuellement

  if (cssLink) {
    try {
      // Récupérer l'attribut href actuel
      const originalHref = cssLink.href;

      const timestamp = new Date().getTime();
      const updatedHref = `${originalHref}?t=${timestamp}`;

      // Mise à jour de l'attribut href
      cssLink.href = updatedHref;

      console.log(`CSS mis à jour : ${updatedHref}`);
    } catch (error) {
      console.error('Erreur lors de la mise à jour du lien CSS :', error);
    }
  } else {
    console.warn('Aucun lien CSS trouvé.');
  }
});

Merci pour tout ce travail.
Cependant, je trouve tout ça un peu lourd pour rafraîchir une page.
Sur le serveur, dans le fichier htaccess, mon css est actuellement à 6s. Pas de problème pour le rafraîchissement, et les perfomances sont très peu altérées.
Et je ne sais toujours pas comment font les grands médias qui changent leur pages et leurs images tous les jours. Ils remettent à zéro leurs pages chaque matin ? Parce qu'il y a parait-il des effets de bord à rafraîchir constamment des pages avec un script.
Sinon, il y a en php:

<?
php header("refresh: 3;"); 
?>

Avec une durée plus longue, bien sûr.
Une solution aussi proposée est la suivante, passer un nombre aléatoire après l'url : echo "<img src='temp.jpg?r=3892384947438'>"
Ce qui évite de renommer le fichier à chaque fois.
Je suis un peu dubidatif face à tout ça. Finalement, la solution de drphilgood semble sans effets de bords, mis à part se mélanger les pinceaux dans les changements.

bonsoir,

Pour reprendre ma proposition qui n'est pas vraiment une astuce mais une possibilité parmis d'autres et pour compléter et ajouter au propos de @OlivierC

Tout d'abord le rafraichissement d'une page et de son cache peut se faire simplement avec CTRL+F5. Un refresh ou reload en javascript en boucle est une très mauvaise idée et agaçant pour n'importe quel visiteur. De nombreux navigateurs d'ailleurs bloque tout simplement ce genre de meta ou script .
Si c'est en cours de dev, le refresh est à automatiser depuis l'éditeur.

Pour reprendre le paramètre de l'url:
Il ne fait aucun doute à aucun d'entre vous qu'une url du type index.php?article=article1 et que index.php?article=article2 sont deux pages distinctes, aussi dans le cache .

Si je reprend avec des fichiers .css ou .js , c'est pareil, en ajoutant un paramètre, c'est une nouvelle url et si elle n'est pas encore en cache, alors il faut la charger.
donc monstyle.css?v=1.0 et monstyle.css?v=1.1 sont deux ressources distinctes

Noter que l'on peut configurer aussi le serveur pour qu'il traite les fichiers comme des fichiers php et se servir des header : voir https://www.php.net/manual/fr/function.header.php .

Donc au moment d'une maintenance et tests répétés pour le front ,
Manuellement, les touches CTRL+F5 vont en principe vider toutes les ressources en cache de la page appeler et la rafraichir entièrement, lorsque l'on veut seulement rafraichir une feuille de styles c'est too much !

En ajoutant un paramètre à L’URL avec une valeur aléatoire derrière, le problème de mise en cache est temporairement réglé pour celui qui est en train de faire cette maintenance
Un timestamp est le plus simple (en js c'est date.now() et en php time() par exemple. monstyle.css?v=timeStamp
Quand les mise à jours sont finies, on incrémente le paramètre initial de 1 pour les visiteurs.

Noter aussi , que la gestion des caches peut s'effectuer depuis le fichier .htaccess aussi (Apache) Nginx à surement aussi les mêmes possibilité.

A mon humble avis,
* Faire recharger la page par votre éditeur de code Sinon, manuellement
* le timeStamp est le plus facile à mettre en place pour zapper le cache coté serveur ( attention au piège ou JavaScript charge une seconde feuille de styles sans la remplacer)
* Ne pas faire de modification sur le site en ligne, seulement la mise à jour.

Enfin, coté serveur, la logique voudrait de vérifier la date de dernière modifications du fichier pour forcer la remise en cache si besoin.

Bonnes fêtes


edit : @bongota je n'avais pas vu ta dernière réponse entretemps.
Pour les images par exemple, traité via htaccess et renvoyées par un script (htaccess pour empêcher l'affichage depuis un autre ndd et php avec header pour gérer le cache et include pour le fichier image. Les possibilité et options de configurations sont nombreuses. C'est comme la gestion des sites multilingues et la soupe à l'oignon. Il n'y a pas qu'une façon de faire, mais des situations, outils, moyens, compétences, choix qui en plus evoluent avec le temps.
Modifié par gcyrillus (26 Dec 2024 - 20:43)

gcyrillus a écrit :
Attention au piège ou JavaScript charge une seconde feuille de styles sans la remplacer

Tu peux expliquer ça STP ?

Olivier C a écrit :

Tu peux expliquer ça STP ?

Il m'est arrivé de vouloir changer l'url d'une feuille de style (je n'ai plus l'exemple sous la main) via JavaScript et de ne pas comprendre pourquoi seulement une partie des styles étaient modifiés et appliqués et pas d'autres.
C'est finalement en regardant dans les outils de dev du navigateur que j'ai vue que la feuille de style lié à L’URL du code source était là, puis plus loin, la seconde une fois que mon petit script avait son œuvre. Les deux feuilles étaient là. Les styles retirés dans la seconde étaient en fait toujours chargés par la première, idem pour les ajouts avec un sélecteur de moindre poids, la première reprenait le dessus alors que je voulais seulement la dernière version.
Dans le source avec l'inspecteur je n'avais qu'une seule balise link qui affichait L’URL modifié.


Cdt

Effectivement, ce comportement est intéressant...
Merci.

En cherchant un peu, j'ai trouvé des informations plus précises sur la configuration du cache du htaccess.
https://developer.mozilla.org/fr/docs/Web/HTTP/Headers/Cache-Control
Notamment :

Cache-Control: max-age=0, must-revalidate

Voici l'explication que j'ai trouvée, ailleurs sur le net.
-------
Pour le contenu généré dynamiquement, ou qui est static mais mis à jour souvent, vous souhaitez qu'un utilisateur reçoive toujours la version la plus à jour.
La plupart des caches HTTP/1.0 ne prennent pas en charge les directives no-cache, donc historiquement, max-age=0 était utilisé comme solution de contournement. Mais seul max-age=0 pouvait provoquer la réutilisation d'un stale response lorsque les caches étaient déconnectés du serveur d'origine. Le must-revalidate répond à ce problème. C'est pourquoi l'exemple ci-dessous est équivalent à no-cache .
--------
La directive de réponse "immutable" est aussi intéressante, elle indique que la réponse ne sera pas mise à jour tant qu'elle est fresh.
J'ai bien sûr "expérimenté, avec max-age=0 et je lai mis sur le css :

<FilesMatch "\\.(css)$">
 Header set Cache-Control "max-age=0, must-revalidate"
 </FilesMatch>

Aussi bien sur Lighthouse que sur Gtmetrix, je n'ai pas eu d'alerte de fichier css au cache trop court ou surtout inexistant. Au contraire, l'alerte a disparu. Jusqu'ici, pas de problèmes. Restera à expérimenter avec un fichier css que j'aurai changé. Ce sera pour plus tard.
Ça parait trop beau, y aurait-il des effets de bord, avec cette directive ?
Modifié par Bongota (28 Dec 2024 - 18:53)