웹 성능 개선 기록 작성법과 템플릿

개선 전 수치를 조건과 함께 적기

성능 개선 기록에서 가장 흔한 실수는 “느렸다”만 적고 어떤 환경에서 어떻게 쟀는지를 빼는 것입니다. 기기, 네트워크, 측정 도구, 반복 횟수를 함께 적어야 개선 후 수치와 비교할 수 있습니다. 이 사이트의 웹 성능 주제 글은 2편이며, 그중 도입 또는 제거처럼 실제 변경이 있었던 사례는 1편입니다.

가설은 근거와 함께 쓰기

깃허브는 사이트 성능을 높이려고 런타임에서 CSS를 만들던 방식을 걷어내고 CSS 모듈로 옮겼습니다. 이 사례처럼 “런타임 작업이 많다”는 가설은 어떤 작업이 얼마나 걸리는지 측정해서 적어야 합니다. 가설이 틀렸을 때 다음에 볼 지표도 함께 적습니다.

숨은 원인을 찾을 때

하테나는 Perl 버전을 올린 뒤 정규표현식 성능이 떨어진 문제의 원인을 찾았습니다. 성능 회귀는 코드 변경보다 런타임이나 라이브러리 버전 변경에서 나오는 경우가 많습니다. 기록에는 “무엇을 바꿨는가”뿐 아니라 “무엇을 바꾸지 않았는가”도 적어야 원인을 좁힐 수 있습니다.

전후 비교표

전후 비교는 같은 조건에서 여러 번 측정한 값으로 씁니다. 한 번 측정한 값 하나로 개선을 주장하지 않습니다. 측정 조건이 다르면 비교표에 그 차이를 칸으로 드러냅니다.

템플릿(복사용)

## 1. 개선 대상과 현재 수치

- 페이지, 지표(예: 첫 화면 표시 시간), 측정 환경

## 2. 가설

- 무엇이 느린 원인이라고 보는가, 근거는 무엇인가

## 3. 변경 내용

- 바꾼 것, 바꾸지 않은 것

## 4. 개선 전후 비교

| 지표 | 전 | 후 | 측정 조건 |
|---|---|---|---|

## 5. 되돌림 기준과 후속 과제

- 되돌릴 지표와 임계값