1초가, 매출을 가릅니다.

몇 해 전, 새로 만든 페이지가 “내 모니터에서는” 빨랐습니다. 그런데 외근 중에 휴대폰 데이터로 열어보니 메인 이미지가 뜨는 데 한참 걸렸습니다. 알고 보니 화면엔 작게 보이는 사진이 원본 그대로, 몇 MB짜리로 올라가 있었습니다. 그날 이후로 저는 “내 컴퓨터에서 빠르다”는 말을 믿지 않습니다. 측정 도구로 본 숫자만 믿습니다.

무엇이 사이트를 무겁게 하나?

경험상 전송 용량의 비중은 거의 항상 같은 순서로 나옵니다. 이미지가 가장 크고, 그다음 JS, 폰트, CSS, HTML 순입니다. 그러니 최적화도 이 순서로 합니다. 코드 한 줄을 줄이는 것보다 큰 사진 한 장을 줄이는 게 효과가 훨씬 큽니다. 말로 하면 와닿지 않으니, 직접 눌러보세요.

이미지, 왜 webp이고 왜 ‘크기’가 핵심인가?

이미지를 줄이는 방법은 두 갈래입니다. 첫째, 형식을 webp(또는 avif)로 바꿉니다. 같은 사진을 JPG보다 훨씬 작은 파일로 담습니다. 둘째, 그리고 이게 더 중요한데, 실제 화면에 보이는 크기로 픽셀을 줄입니다. 화면에서 400px 폭으로 보이는데 2000px 원본을 올려두는 일이 정말 흔합니다. 브라우저가 그걸 다 받아서 작게 줄여 그릴 뿐이라, 사용자는 보이지도 않는 픽셀을 다운로드하느라 기다립니다. 위 위젯에서 ‘이미지’ 막대가 가장 크게 줄어드는 이유가 이겁니다.

폰트 용량을 0으로 만드는 법?

예쁜 웹폰트 하나가 수백 KB를 더합니다. 그런데 글꼴이 다 받아지기 전까지 글자가 안 보이거나 깜빡이기도 합니다. 저는 본문에 시스템폰트를 기본으로 씁니다. -apple-system, "Segoe UI", "맑은 고딕"처럼 사용자 기기에 이미 있는 글꼴을 쓰면 다운로드할 파일이 없어 폰트 전송 용량이 그냥 0이 됩니다. 위 위젯에서 폰트 막대가 0까지 내려가는 게 그 얘기입니다. 브랜드 글꼴이 꼭 필요한 제목 정도에만 woff2로, 그것도 쓰는 글자만 서브셋해서 가볍게 씁니다.

JS는 적을수록 빠른가? 외부 의존은?

JS는 받아서, 해석하고, 실행까지 해야 하므로 같은 용량이라도 이미지보다 더 ‘비쌉니다’. 저는 효과 하나 때문에 무거운 라이브러리를 통째로 부르지 않습니다. 필요한 동작은 짧은 바닐라 코드로 직접 씁니다. 특히 외부 스크립트(광고·트래커·위젯)는 우리가 통제할 수 없는 남의 서버 속도에 우리 페이지를 묶어버립니다. 그래서 꼭 필요한 것만, 가능하면 지연 로딩으로 붙입니다.

한 번 받은 건 또 받지 않게 — 캐싱?

처음 방문은 어쩔 수 없이 받습니다. 하지만 두 번째부터는 달라야 합니다. CSS·JS·이미지에 캐시 정책을 잘 걸어두면 재방문자는 브라우저에 저장된 파일을 그대로 써서 거의 즉시 뜹니다. 파일 내용이 바뀌면 이름을 바꿔(버전 표시) 새로 받게 하고, 안 바뀐 건 오래 캐싱합니다. 이 한 가지가 단골 방문자의 체감 속도를 크게 바꿉니다.

코어 웹 바이탈, 무엇을 보나?

구글이 보는 ‘사용자 체감’ 지표 세 가지입니다. LCP는 가장 큰 콘텐츠(보통 큰 이미지나 제목)가 뜨는 시간, INP는 사용자가 무언가를 누른 뒤 화면이 반응하는 시간, CLS는 읽는 도중 화면이 갑자기 밀리는 정도입니다. 이미지에 가로·세로 크기를 미리 적어두면 CLS가 안정되고, 무거운 JS를 줄이면 INP가 좋아지고, 큰 이미지를 줄이면 LCP가 빨라집니다. 앞에서 한 일들이 전부 이 셋으로 돌아옵니다.

제가 작업 전후로 보는 화면은 이런 식입니다. 아래는 측정 도구의 출력 형태를 보여주는 예시 값으로, 같은 페이지를 손보기 전과 후에 어떻게 달라지는지를 한눈에 비교하려는 것입니다.

$ lighthouse https://example.kr --only-categories=performance

  Before  LCP 4.1 s    INP 360 ms   CLS 0.21   ← 무거운 이미지·JS
  ───────────────────────────────────────────
  webp 전환 + 표시크기 리사이즈 ........ 이미지 -71%
  시스템폰트 적용 ...................... 폰트   -100%
  비핵심 JS 지연 로딩 ................. JS     -58%
  img width/height 명시 .............. CLS 안정화
  ───────────────────────────────────────────
  After   LCP 1.7 s    INP 150 ms   CLS 0.02   ✓ 모두 '좋음'

  # 수치는 측정 도구 출력 형태를 보여주는 예시이며 환경마다 다릅니다.

숫자가 이렇게 한 줄로 정렬되면, 다음에 어디를 손봐야 가장 크게 빨라지는지가 분명해집니다.

그래서, 무엇부터 하나? — 측정이 먼저다

가장 중요한 원칙은 이겁니다. 고치기 전에 측정합니다. 감으로 “이게 느린 것 같아”라며 손대면, 정작 무거운 건 그대로 두고 사소한 걸 다듬게 됩니다. 실제 사용자 환경 데이터를 보고, 가장 무거운 항목(거의 항상 이미지)부터 순서대로 내려갑니다. 위 위젯의 ‘이미지 → JS → 폰트 → CSS → HTML’ 순서가 곧 제 작업 순서입니다.

다른 담당자와의 연결

성능은 혼자 만드는 숫자가 아니라 합작입니다. 가장 무거운 이미지를 어떻게 다루는지는 이미지 담당자의 노트에, 기다리는 시간을 어떻게 ‘덜 느리게’ 연출하는지는 로딩 담당자의 노트에, 그리고 애초에 가벼운 코드로 짓는 우리 개발 방식은 개발은 이렇게 합니다에 적어두었습니다. 이 셋이 맞물려야 1초가 지켜집니다.