JSON 압축

압축은 파서가 어차피 무시하는 공백을 한 바이트도 남기지 않고 없앱니다. 줄바꿈, 들여쓰기, 콜론 뒤의 공백. 그 밖에는 아무것도 바뀌지 않고, 파싱한 결과는 완전히 같습니다.

일반적인 정렬된 API 페이로드라면 전체 바이트의 10~20퍼센트가 사라집니다. 공백 4칸으로 정렬한 깊은 중첩 문서라면 3분의 1을 넘기도 합니다.

실제로 도움이 되는 곳과 그렇지 않은 곳

대량으로 저장되거나 전송되는 것에는 압축할 값어치가 있습니다. API 응답, 번들에 구워 넣는 설정, 큐에 쌓이는 레코드, 컬럼 스토어의 행 같은 것들입니다.

HTTP 위에서는 사람들이 기대하는 것보다 훨씬 값어치가 적습니다. gzip과 brotli가 반복되는 공백을 이미 아주 잘 압축하기 때문입니다. 이미 gzip이 걸린 응답을 압축해 봐야 대개 몇 퍼센트를 아낄 뿐, 20퍼센트가 아닙니다. 여전히 중요한 곳은 압축이 적용되지 않는 자리입니다. 로컬 스토리지, 데이터베이스 컬럼, 크기 상한이 빡빡한 메시지 본문, 로그 한 줄.

사람이 읽는 파일에는 아무 값어치도 없습니다. 압축된 JSON은 거대한 한 줄이고, 거기에 생기는 모든 diff는 파일 전체를 다시 쓴 것으로 보입니다.

압축이 하지 않는 일

키를 줄이거나, null 값을 버리거나, 순서를 바꾸거나, 숫자를 손대지 않습니다. 그건 서식이 아니라 데이터 자체를 바꾸는 일이고, 그것을 조용히 하는 압축기는 위험합니다.

특히 숫자는 원래 텍스트 그대로 남습니다. JSON.parse 위에 만든 압축기라면 1.50은 1.5로, 1e3은 1000으로 바뀝니다. 더 짧아지긴 하지만 그것은 다른 문서입니다.

How to do this in code

코드에서 압축하는 방법입니다.

const min = JSON.stringify(JSON.parse(text));

// Note this also normalises numbers: 1.50 becomes 1.5.

import json

# The separators argument is the part people miss: without it
# Python leaves a space after every comma and colon.
min_text = json.dumps(json.loads(text), separators=(',', ':'))

jq -c . input.json > output.min.json

var buf bytes.Buffer
if err := json.Compact(&buf, data); err != nil {
    return err
}
// Compact works on bytes, so numbers are untouched.

자주 묻는 질문

실제로 얼마나 줄어드나요?

이 도구는 여러분의 문서에 대해 전후 바이트 수를 보여 줍니다. 대략적으로 공백 2칸으로 정렬한 JSON은 10~20퍼센트가 공백이고, 4칸이면 더 많습니다. gzip이 걸린 연결에서는 압축이 이미 반복을 잘 처리하기 때문에 실제 절감폭이 훨씬 작습니다.

압축한 JSON도 여전히 유효한가요?

네. 토큰 사이의 공백은 의미가 없으므로, 압축한 문서와 정렬한 문서는 정확히 같은 값으로 파싱됩니다.

저장소 안의 JSON도 압축해야 하나요?

아닙니다. 버전 관리는 사람이 diff를 읽으라고 있는 것이고, 압축된 파일에서는 모든 변경이 전체 재작성처럼 보입니다. 압축은 빌드할 때나 보낼 때 하세요.