Minification ou mise en forme du JSON : quand utiliser chaque

Ce qui change entre les deux

La minification supprime chaque octet qui ne change pas le sens : les espaces après les deux-points et les virgules, les sauts de ligne et l'indentation. La mise en forme (aussi appelée embellissement) remet ces espaces selon un motif cohérent, en général 2 ou 4 espaces par niveau d'imbrication, pour que vous voyiez la structure d'un coup d'œil.

// Minified (48 bytes)
{"user":{"id":7,"active":true,"tags":["a","b"]}}

// Prettified (2-space indent, 96 bytes)
{
  "user": {
    "id": 7,
    "active": true,
    "tags": ["a", "b"]
  }
}

Les deux s'analysent en un même objet en mémoire. Les 48 octets supplémentaires de la version mise en forme servent la lisibilité humaine et ne portent aucune information sémantique.

Quand la minification est le bon choix

Réponses et requêtes d'API : chaque octet supprimé est un octet que le client ne télécharge pas. Sur une grosse charge utile, comme une liste paginée de centaines d'enregistrements, la minification peut retirer 15 à 25 % de la taille transférée avant que la compression n'intervienne.

Configuration intégrée dans des bundles HTML ou JS : un blob JSON minifié inséré dans une balise <script> n'alourdit pas votre bundle d'un formatage dont aucun navigateur n'a besoin.

Lignes de journal et stockage : si vous écrivez du JSON dans un fichier de journal ou une colonne de base à raison d'un enregistrement par ligne, minifier garde chaque enregistrement sur une seule ligne, et des outils comme grep, jq -c et les expéditeurs de journaux ligne par ligne en dépendent.

Une réserve : si vous servez déjà vos réponses avec une compression gzip ou brotli (c'est le cas de la plupart des API), le gain d'octets de la minification fond, car les espaces répétés se compressent très bien. Minifiez pour les cas non compressés (configurations intégrées, journaux), là où le gain est le plus net.

Quand la mise en forme est le bon choix

Tout ce qu'un humain lira : exemples de documentation d'API, fichiers de configuration que les développeurs éditent à la main (package.json, tsconfig.json), sortie de débogage et diffs de revue de code. Un blob JSON minifié sur une ligne apparaît dans un diff git comme une seule ligne modifiée, aussi petit que soit le changement, alors que le JSON mis en forme donne un diff propre ligne par ligne, facile à relire.

Configuration versionnée : une indentation de 2 ou 4 espaces avec une clé par ligne permet à git de montrer exactement quelle clé a changé, au lieu de marquer tout le blob comme modifié.

2 espaces, 4 espaces ou tabulations

JSON.parse() ignore l'indentation, donc ce choix n'a aucun effet fonctionnel. 2 espaces est la convention la plus courante dans les écosystèmes JavaScript/TypeScript (npm, la plupart des guides de style JS) et évite que les objets très imbriqués débordent de l'écran. 4 espaces se rencontre plus dans les outils proches de Python. Les tabulations sont rares en JSON, car éditeurs et visionneuses de diff les affichent de façon incohérente. Choisissez-en une et tenez-vous-y dans tout le projet, car l'indentation mixte produit des diffs bruyants.