[Firefox] Mauvaise prise en compte des requêtes qui tapent le cache

[bhennesAdv]

Bonjour,

Je rencontre le problème actuellement sur Firefox 138.0.4 (64 bits) sur Ubuntu.
Le problème n'est pas présent dans Chrome.

Les requêtes effectuées plusieurs fois dans la même page sont automatiquement mises en cache par Firefox (Par exemple une image).
Exemple sur la page https://greenit.eco/ :
L'image https://greenit.eco/wp-content/uploads/2024/11/gri-logo-asso-regular-dark.svg est chargée 2 fois dans la page.
Elle apparaît 2 fois dans l'onglet Réseau (Un appel réel et un appel dont la taille de transfert est "mis en cache").
A la différence de Chrome où la requête n’apparaît qu'une seule fois

Ces requêtes devraient être ignorés dans les différents calculs du plugin car les informations qu'ils contiennent sont erronées :

• La taille de la réponse est incorrecte : 118.37Ko dans mon cas alors que l'image fait 14.21Ko.
• Le protocole utilisé est incorrect : HTTP/1.1 alors que la requête originale est en HTTP/2 et qu'en tapant le cache, le protocole importe peu.

Cela est sans doute plus ou moins corrélé avec les autres issues qui remontent que les données entre les différents navigateurs sont différentes.
Par exemple, sur l'un de mes sites de test, le nombre de requête sur la page passe de 398 sur chrome à 440 sur Firefox uniquement parce certaines images (A priori une 40aine) sont inclues 2 fois dans le DOM.
Pour la même raison, le plugin me remonte une erreur sur l'utilisation d'HTTP/2 car toutes les images provenant du cache remontent en utilisant HTTP/1.1

Je ne peux pas ouvrir de PR car je ne connais pas assez bien le format HAR pour savoir quelle donnée est pertinente à vérifier pour valider que la requête vient bien d'un cache :
Ci-dessous, un exemple de résultat HAR pour le retour du cache.

{
        "startedDateTime": "2025-05-23T10:53:42.198+02:00",
        "request": {
          "bodySize": 0,
          "method": "GET",
          "url": "https://greenit.eco/wp-content/uploads/2024/11/gri-logo-asso-regular-dark.svg",
          "httpVersion": "HTTP/1.1",
          "headers": [
            {
              "name": "Host",
              "value": "greenit.eco"
            },
            {
              "name": "User-Agent",
              "value": "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:138.0) Gecko/20100101 Firefox/138.0"
            },
            {
              "name": "Accept",
              "value": "image/avif,image/webp,image/png,image/svg+xml,image/*;q=0.8,*/*;q=0.5"
            },
            {
              "name": "Accept-Language",
              "value": "fr,fr-FR;q=0.8,en-US;q=0.5,en;q=0.3"
            },
            {
              "name": "Accept-Encoding",
              "value": "gzip, deflate, br, zstd"
            },
            {
              "name": "Referer",
              "value": "https://greenit.eco/"
            }
          ],
          "cookies": [],
          "queryString": [],
          "headersSize": 0
        },
        "response": {
          "status": 200,
          "statusText": "OK",
          "httpVersion": "HTTP/1.1",
          "headers": [],
          "cookies": [],
          "content": {
            "mimeType": "image/svg+xml",
            "size": 118368,
            "text": ""
          },
          "redirectURL": "",
          "headersSize": 0,
          "bodySize": 0
        },
        "cache": {},
        "timings": {},
        "time": 0,
        "pageref": "page_2"
      }

Plusieurs détails peuvent sans doute permettre d'identifier que ce n'est pas une vraie requête :
response.bodySize == 0 ET response.headersSize == 0 : A priori, je ne vois aucun cas où une réponse HTTP ne renverrait ni contenu ni header ? Peut être à cumuler avec response.content.size != 0 ? Car une requête avec un contenu mais sans body me semble assez peu concevable dans un autre cas ?
timings == {} : A priori, sans timing, une requête n'a pas été exécutée et est donc une "fausse" requête ?
time == 0 : Même constat qu'avant, a moins d'avoir une réponse instantanée d'un serveur ?

Qu'en pensez-vous ?
Cordialement,
Baptiste