“사이트가 느립니다” 라는 말만으로는 고칠 곳을 정할 수 없습니다. 느린 것이 서버가 응답을 만드는 시간인지, 전송 구간인지, 브라우저가 화면을 그리는 단계인지에 따라 손대야 할 파일이 완전히 다르기 때문입니다. 워드프레스는 세 구간 모두에서 잘 동작하도록 만들어진 도구이고, 느려지는 것은 대개 어느 한 구간이 방치됐을 때입니다.
그래서 최적화 작업의 첫 30분은 코드를 여는 시간이 아니라 구간을 나누고 숫자를 얻는 시간입니다. 이 순서를 건너뛰면 대개 무언가는 개선되지만, 개선된 그것이 병목이 아니어서 체감이 그대로입니다.
구간을 세 개로 나눕니다
브라우저가 주소를 요청한 뒤 화면이 완성되기까지를 세 구간으로 나눕니다. 각 구간은 원인도 도구도 다릅니다.
첫 구간을 재는 가장 단순한 방법은 curl 입니다. 응답의 첫 바이트가 오기까지의 시간만 뽑으므로 브라우저 · 확장 프로그램 · 캐시의 영향을 받지 않습니다.
curl -s -o /dev/null -w '%{time_starttransfer}n' https://example.com/이 값이 작은데 화면이 늦게 뜬다면 서버는 문제가 아닙니다. 반대로 이 값이 크다면 브라우저 개발자 도구를 아무리 들여다봐도 답이 나오지 않습니다 — 다음 회차의 쿼리 프로파일로 넘어가야 하는 신호입니다.
측정 프로토콜 — 조건을 고정합니다
측정값은 조건을 고정해야 비교할 수 있습니다. 다섯 가지를 매번 같게 둡니다.
로그인 상태가 특히 자주 어긋납니다. 관리자로 로그인한 브라우저는 페이지 캐시를 우회하도록 구성돼 있는 것이 정상이므로, 그 상태의 측정치는 방문자 경험이 아닙니다. 관리자 화면이 느린 것과 방문자 화면이 느린 것은 별개의 문제이고 원인도 대체로 다릅니다.
3회 중앙값은 형식적인 규칙이 아닙니다. 첫 요청은 캐시 미스, 그다음은 히트, 그 사이에 이웃 사이트의 부하가 겹치면 같은 URL 에서도 값이 크게 흔들립니다. 한 번 잰 값으로 “2배 빨라졌다” 고 적으면 다음 측정에서 반박됩니다.
가설은 한 번에 하나입니다
구간이 좁혀졌으면 가설을 하나 세우고 하나만 바꿉니다. 한 번에 셋을 바꾸면 좋아졌을 때 무엇이 기여했는지 모르고, 나빠졌을 때 무엇을 되돌려야 하는지도 모릅니다. 한 바퀴의 최소 단위는 구간 나누기 → 가설 하나 → 변경 하나 → 재측정 → 기록이고, 이 고리를 짧게 유지하는 것이 작업 전체의 속도를 정합니다.
고리가 기록으로 끝나는 데는 이유가 있습니다. 개선된 항목뿐 아니라 개선되지 않은 항목도 함께 적습니다. 선택적으로 좋은 숫자만 남기면 그 리포트는 한 번 반박당하는 순간 나머지 수치의 신뢰까지 잃습니다. “이 항목은 바꿨지만 변화가 없었다” 는 문장은 다음 사람이 같은 길을 다시 걷지 않게 해 주는, 가장 값싼 자산입니다.
측정 도구와 지표를 더 깊이 다루는 글은 성능 최적화 아카이브에 모여 있고, 전/후 측정을 포함한 실제 작업 절차는 작업 과정에 그대로 공개돼 있습니다.
다음 회차
서버 처리 구간이 범인으로 좁혀졌다면 이제 쿼리를 봅니다. 다음 회차는 쿼리 프로파일을 읽는 법 — 느린 쿼리와 중복 쿼리는 다른 문제이고, 고치는 방법도 다릅니다.