Un gros fichier JSON ne s'ouvre pas : choisissez le bon outil selon la taille

Un fichier JSON de 45 Mo se parse en 249 millisecondes. La demi-minute d'attente vient du rendu de ses cinq millions de lignes de texte et de 3,5 millions de nœuds d'arbre. Confondez les deux, et vous chercherez toujours le mauvais coupable.

Un : mesurer d'abord — le parsing n'est jamais le goulot d'étranglement

Double-cliquez sur un export .json de plusieurs dizaines de Mo, regardez l'éditeur tourner trente secondes, et le réflexe dit « le parsing JSON est lent ». Les mesures disent le contraire. Sur notre machine (Node 22), nous avons généré un échantillon de 500 000 enregistrements de cinq champs chacun (id, email, active, score, tags), soit 45 Mo en forme compacte :

Le parsing s'est terminé en un quart de seconde. Le parseur avait fini avant que vous ne relâchiez la souris. Toutes les secondes suivantes se sont écoulées dans la couche « montrer le résultat à un humain » : l'éditeur de texte doit mettre en page cinq millions de lignes, appliquer la coloration syntaxique et tenir un tampon d'annulation ; l'arborescence doit créer un élément DOM pour chacun des 3,5 millions de nœuds — et les navigateurs s'essoufflent autour de cent mille nœuds, perdant toute réactivité bien avant le million.

La conclusion pointe dans une direction totalement différente : cessez de vous battre avec le rendu et prenez un outil qui ne rend pas tout.

Deux : pourquoi ça fige — le nombre de lignes et de nœuds est le vrai coût

La taille du fichier n'est que la surface. Deux nombres dérivés cassent réellement les outils :

1. Le nombre de lignes. Un JSON compact de 45 Mo devient cinq millions de lignes une fois indenté. Quelle que soit la portion affichée, l'éditeur doit d'abord construire la structure de lignes de tout le fichier, résoudre l'état de coloration et allouer des tampons — des coûts proportionnels au total de lignes.
2. Le nombre de nœuds. Un demi-million d'enregistrements × (un objet + cinq champs), c'est 3,5 millions de nœuds. Tout visionneuse qui construit l'arbre entier avant d'afficher paie la même mémoire et le même temps que vous déployiez une branche ou toutes.

Deux conséquences contre-intuitives en découlent. Indenter avant de regarder dessert — le fichier passe de 45 à 71 Mo et le nombre de lignes est multiplié par quarante, une pression purement ajoutée à l'outil. Envoyer le fichier par cat dans un terminal dessert aussi — le tampon de défilement devient le nouveau goulot ; pour les premiers octets, head -c 2000 suffit.

Trois : choisir l'outil selon la taille — une table de décision

Des tailles différentes appellent des outils complètement différents. En combinant les mesures ci-dessus avec les repères publiés par les sites d'outils (OpenFormatter situe la zone de confort des outils en ligne à 2-5 Mo ; PureJSON estime la mémoire après parsing d'un document de 500 Mo entre 2 et 4 Go), on obtient cette table :

L'outil /parse de ce site couvre le premier échelon : arborescence et validation. Pour plus grand, préférez l'application de bureau pour éviter de coller des dizaines de Mo dans une page web.

Quatre : n'ouvrez pas le fichier — demandez d'abord sa structure

Face à un gros JSON inconnu, le premier geste n'est pas l'ouverture mais quelques secondes pour comprendre sa forme. jq répond à trois questions en environ 200 ms :

复制# Tableau ou objet au sommet ? Combien d'enregistrements ?
jq 'if type == "array" then {type: "array", count: length} else {type: "object", keys: (keys|length)} end' huge.json

# À quoi ressemble le premier enregistrement (un seul, pas de déluge) ?
jq '.[0]' huge.json | head -40

# Tous les noms de champs (pris sur le premier enregistrement)
jq '.[0] | keys' huge.json

Une fois la structure connue, la plupart des demandes se réduisent à « extraire un champ » — le fichier n'a même pas besoin d'être ouvert. Par exemple, pour récupérer l'e-mail de chaque utilisateur :

复制jq -r '.[].email' huge.json | less
# Empilez un filtre
jq -r '.[] | select(.active == true) | .email' huge.json

La règle est simple : pour regarder, un visionneuse au rendu virtualisé ; pour chercher et extraire, jq. Ne mélangez pas les deux rôles dans un seul outil.

Cinq : la falaise mémoire — mode normal contre flux, 150 fois d'écart

Sur le même échantillon de 45 Mo, /usr/bin/time -v a mesuré la mémoire de crête de jq dans deux modes :

Le mode normal lit tout le fichier et construit le graphe d'objets ; le pic de 542 Mo confirme la règle « graphe d'objets ≈ 7-12× la taille du texte ». --stream consomme l'entrée jeton par jeton, en gardant la mémoire à quelques Mo — au prix d'une durée totale plus longue. Au-delà du gigaoctet, cette différence sépare « ça tourne » de « tué par l'OOM killer » :

复制# Pour des fichiers plus gros que la mémoire : --stream est le seul mode qui ne charge jamais tout
jq --stream -n 'fromstream(1|truncate_stream(inputs))' huge.json

L'équivalent Python est ijson : ijson.items(f, 'item') produit les éléments du tableau un par un avec la même mémoire constante. Le prix commun de ces outils est l'abandon de l'accès aléatoire — un flux est un seul passage en avant, et un second passage suppose une nouvelle lecture.

Six : jusqu'où le navigateur peut-il aller — les limites du traitement local

Les outils en ligne sont utilisables, dans des limites. Un onglet de navigateur moderne dispose d'environ 1 à 4 Go de mémoire ; un fichier de 45 Mo parsé en graphe plus arbre survit généralement. Quelques centaines de Mo approchent de la falaise. En choisissant un visionneuse en ligne, exigez trois choses :

1. Le traitement se fait localement (le contenu collé n'est jamais envoyé à un serveur), ce qui protège les données et économise le temps d'envoi — tous les outils de ce site tournent entièrement dans le navigateur et fonctionnent hors ligne ;
2. Le parsing tourne dans un Web Worker — le fil principal ne gèle pas, et un blocage coûte un onglet plutôt que tout le navigateur ;
3. L'arbre est virtualisé ou à déploiement paresseux — les branches repliées ne coûtent presque rien, seul ce qui est déployé est rendu.

Sur ce site : /parse convient à l'exploration de structure et au repérage d'erreurs jusqu'à quelques dizaines de Mo ; au-delà, jq ou l'application de bureau, le navigateur gardant les petits fragments.

Sept : le bon format supprime la moitié des problèmes

Si vous influencez la façon dont le fichier est produit, un meilleur visionneuse est le mauvais remède — faites en sorte qu'il ne devienne pas « un gigantesque tableau unique » :

• NDJSON/JSONL : un enregistrement par ligne. L'ajout ne réécrit pas le fichier, head, grep, tail, split fonctionnent directement ; un fichier tronqué ne perd que sa dernière ligne. Notre guide JSONL détaille le tri des lignes cassées.
• Exports paginés : une API qui renvoie 100 000 enregistrements devrait accepter des paramètres de pagination — 100 à la fois, plus confortable pour les deux parties.
• Les données tabulaires ne sont pas du JSON : un enregistrement par ligne, champs fixes sans imbrication — c'est une table. CSV ou Parquet sont plus compacts et mieux outillés.

Un chiffre à retenir : coupez en deux un tableau de 500 000 enregistrements, la première moitié reste un fichier NDJSON valide (la moitié des enregistrements survit), tandis que le tableau unique correspondant est perdu intégralement. 500 enregistrements récupérés sur 501 valent mieux que zéro.

Huit : liste de contrôle

• Sondez d'abord la structure avec jq '.[0] | keys' ou un échantillon de 500 enregistrements ;
• N'indentez jamais juste pour ouvrir un fichier — doubler les lignes ne fait que ralentir ;
• Moins de 2 Mo : arborescence en ligne ; plus de 20 Mo : ligne de commande ; plus de 1 Go : toujours --stream ou ijson ;
• Vérifiez que l'outil en ligne traite localement (le contenu collé ne quitte pas le navigateur) ;
• Si vous maîtrisez le producteur, passez au NDJSON ou à la pagination et éliminez les gigantesques tableaux à la source.

FAQ

Pourquoi l'éditeur met-il des dizaines de secondes à ouvrir le JSON quand le programme le parse en 200 ms ?

Le parsing est du code natif qui convertit le texte en structure de données : 249 ms pour notre échantillon de 45 Mo. L'éditeur bute sur la présentation : cinq millions de lignes à mettre en page, colorer et tamponner pour l'annulation ; l'arbre construit un DOM de 3,5 millions de nœuds. Un visionneuse virtualisé ou une extraction directe par jq contourne tout cela.

jq déborde-t-il sur des JSON de plus de 1 Go ?

En mode normal, oui : il charge tout le document et le graphe d'objets culmine à 7-12× la taille du fichier. Avec --stream, l'entrée est consommée jeton par jeton : notre test de 45 Mo a culminé à 3,6 Mo de mémoire, qui reste plate quelle que soit la taille du fichier — au prix d'un seul passage séquentiel.

Quelle taille de fichier les outils JSON en ligne supportent-ils ?

La plupart sont à l'aise jusqu'à 2-5 Mo et se dégradent nettement au-delà de 10 Mo. Le plafond strict est la mémoire de l'onglet (environ 1-4 Go), mais dès quelques dizaines de Mo l'attente du parsing et de la construction d'arbre devient pénible. Au-delà de 20 Mo, passez à un outil local ou à la ligne de commande.

Comment lire la valeur d'un seul champ dans un JSON énorme ?

Extrayez avec jq sans ouvrir le fichier : jq -r '.[].email' huge.json affiche tous les e-mails ; ajoutez un filtre avec jq -r '.[] | select(.active == true) | .email'. Pour les premiers enregistrements, jq '.[0:5]' huge.json — des ordres de grandeur plus rapide que l'ouverture.

Indenter avant d'ouvrir aide-t-il ?

Non. L'indentation transforme 45 Mo compacts en 71 Mo et une ligne unique en cinq millions, n'ajoutant que du travail pur à l'éditeur et au visionneuse. Réservez l'indentation aux fichiers destinés à être lus — et assez petits pour l'être.