Cache Web: un aspect crucial, mais excentrique du développement Web. Entre votre navigateur et le serveur se trouve un réseau complexe de caches, optimisant silencieusement le trafic Internet. Cependant, ce système même peut introduire des incohérences déroutantes si elle n'est pas soigneusement gérée.

Prise des clés:

• La mise en cache Web repose fortement sur les codes et les en-têtes d'état HTTP (comme Last-Modified, Etag, et Cache-Control). Cache-Control est primordial, offrant des options telles que no-store, no-cache, public, private, et max-age.
• Chrome et Edge présentent des comportements uniques. Pour éviter les conflits de mise en cache, en particulier avec les appels AJAX, utilisez des URL distinctes pour le contenu de la page et les données AJAX. Cela évite le scénario où Cached JSON remplace Html.
• Les certificats SSL auto-signés perturbent la mise en cache dans Chrome et les navigateurs similaires. Ils désactivent efficacement la mise en cache, conduisant à des écarts entre les tests locaux et les déploiements en direct.

Gestion de l'en-tête HTTP:

Le comportement de mise en cache est dicté par les codes de statut HTTP et les en-têtes. Un navigateur / proxy servira soit des données mises en cache, vérifiera la fra?cheur des données avec le serveur ou récupérera de nouvelles données. L'en-tête Cache-Control est la clé:

• no-store ou no-cache: no-store empêche toute mise en cache; no-cache permet au navigateur / proxy de vérifier auprès du serveur en utilisant Last-Modified et / ou Etag avant de servir des données mises en cache.
• public ou private: public permet de mettre en cache partout; private restreint la mise en cache au navigateur de l'utilisateur.
• max-age: Spécifie la période de validité du cache en secondes.

Exemple (php):

header('Cache-Control: private,max-age=30');
echo json_encode($data);

Exemple (node.js / express):

res
    .set('Cache-Control', 'private,max-age=30')
    .json(data);

URL distinctes pour les pages et les données ajax:

Même avec des paramètres d'en-tête appropriés, les incohérences du navigateur peuvent survenir, en particulier lors de l'utilisation du bouton de retour. Chrome et Edge pourraient revenir à l'état de page initial, tandis que Firefox et Safari conservent le dernier état connu.

Considérons une table paginée:

1. Chargement de la page initiale: http://myapp.com/list/
2. Ajax Navigation: L'URL change (par exemple, http://myapp.com/list/?search=bob&page=42), mais Ajax met à jour le dom.

Si l'appel Ajax utilise la même URL, Chrome / Edge peut servir JSON en cache au lieu de HTML lorsque le bouton arrière est enfoncé. La solution: utilisez des URL séparées pour les demandes de page et ajax (par exemple, ajouter &ajax=1 à l'URL AJAX). Cela garantit une mise en cache indépendante.

Le péril des certificats SSL auto-signés:

Bien que pratique pour le développement, les certificats auto-signés empêchent le chrome (et probablement d'autres navigateurs basés sur des clignotements) de mettre en cache les données de la page. Cela crée des incohérences entre les tests locaux (pas de mise en cache) et les déploiements en direct (mise en cache activé).

Questions fréquemment posées (FAQ):

La section FAQ fournie reste largement inchangée, car elle offre des informations précieuses sur la mise en cache des meilleures pratiques et le dépannage. Le contenu est déjà bien structuré et répond aux préoccupations communes liées à la mise en cache des réponses JSON et aux stratégies globales de développement Web.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!