화면을 빠르게 만들자는 요청에서 캐시나 서버부터 바꾸기 쉬웠다. 하지만 K-POP PULSE의 8월 6일 최적화 기록은 응답 지표와 HTML 구성부터 나누어 읽었다. 데스크톱과 모바일 메뉴가 같은 대상을 두 번 출력하고 있다는 점이 구체적인 수정 대상이 되었다.
나는 이 이야기를 현재 사이트의 속도 홍보로 쓰지 않는다. 당시 측정 문서의 전후 비교와 실제 템플릿·JavaScript 변경을 함께 읽고, 처음 적은 잘못된 기대 수치가 어떻게 정정됐는지 설명한다. 측정이 무엇을 증명하는지도 구현처럼 관리해야 했다.
응답이 균일해도 화면의 비용은 남아 있다
당시 문서는 여러 경로의 응답 시간이 비슷하고 엣지 캐시 HIT라는 측정을 먼저 기록했다. 이어 대상 페이지의 원본 HTML을 구성 요소별로 살펴보았다. 이 자료는 서버나 캐시를 무조건 더 고치는 대신 실제 중복 마크업을 읽을 근거가 되었다.
다만 문서는 캐시가 측정 URL을 정규화했으므로 그 결과로 오리진의 독립 성능을 재는 것은 아니라고도 적는다. 나는 작은 쿼리 문자열을 붙였다고 곧바로 캐시를 우회했다고 믿지 않는다. 측정 경로·환경·관측한 응답을 함께 남겨 그 숫자의 한계를 읽는다.
숨긴 목록도 출력 비용에서는 두 벌이었다
초기 템플릿에는 모바일 바와 데스크톱 독이 같은 목록의 루프를 각각 실행했다. CSS가 어느 쪽을 보여 줄지 정하더라도 HTML에는 양쪽의 항목이 있었다. 당시 변경 입력과 이전 문자열을 직접 대조하면 이 중복이 단순한 추측이 아니라 같은 자료를 두 번 출력한 구조였음을 확인할 수 있다.
나는 표시 여부와 출력 여부를 나눈다. 화면에서 안 보이는 요소가 있다고 그 자료와 이미지 태그가 처음부터 생성되지 않았다는 뜻은 아니다. 그렇다고 모든 숨김이 불필요한 중복인 것도 아니다. 서로 같은 역할을 하는지와 다른 화면 상태를 위해 필요한지부터 대조해야 한다.
한 목록으로 합친 뒤 상태 처리도 함께 바뀌었다
8월 6일 수정은 한 nav를 만들고 CSS가 가로·세로 방향을 정하게 했다. JavaScript도 두 요소를 각각 찾던 방식에서 실제 flex-direction을 읽는 방식으로 바뀌었다. 가로 바와 세로 독의 위치를 다른 저장 키로 읽는 수정이 이어졌다. 마크업만 줄이고 동작은 이전 요소를 찾도록 남겨 둔 것이 아니다.
공유한 새 설명 골격도 목록을 한 번 출력하는 관계를 보여 준다. 실제 적용에서는 이벤트를 붙이는 대상, 선택한 식별자, 스크롤 축, 저장 키와 폭 경계의 본문 여백을 함께 확인한다. 원본의 구조 변경을 자신의 사이트에서 같은 모습과 기능으로 옮기는 일이 별도의 통합 검사다.
코드와 구현 살펴보기
새 설명 골격. 원본 템플릿과 당시 벤치마크의 복원본이 아니다.
<nav class="subject-rail" aria-label="Subjects">
<!-- Render each subject once with its stable data-id. -->
</nav>
.subject-rail { display:flex; flex-direction:row; overflow:auto; }
@media (min-width: 900px) {
.subject-rail { flex-direction:column; max-height:20rem; }
}
/* This new skeleton is not the original template or a measured benchmark. */전후 숫자는 같은 비교표 안에서 읽는다
최적화 문서의 해당 로컬 비교에는 대상 페이지 HTML 196KB에서 154KB, 이미지 태그 285개에서 190개라는 결과가 적혀 있다. 이 값은 당시 그 비교의 범위다. 지금의 전체 사이트 크기나 전세계 방문자의 체감 시간으로 다시 설명하지 않는다.
문서 앞쪽의 구성 분석에는 다른 관측값도 있어 모든 숫자를 하나의 동일한 샘플로 합치지 않는다. 압축 전 HTML 크기, 전송 바이트와 태그 수는 같은 지표도 아니다. 개선을 설명하려면 무엇을 같은 조건에서 비교했는지 남겨야 숫자가 구현의 원인을 정확하게 받쳐 준다.
잘못된 목표를 정정하는 일도 작업에 포함됐다
최초 템플릿 주석에는 중복을 82KB와 아바타230여 개로 설명한 부분이 남아 있다. 그러나 최적화 문서는 한 벌에서 줄일 수 있는 양과 초기 수용 기준의 계산이 틀렸다고 정정한다. 나는 이전 주석의 큰 숫자를 그대로 성과 문장으로 가져오지 않았다.
더 줄이려면 목록 길이나 렌더 시점을 바꾸는 별도 작업이 필요하다는 경계도 남아 있다. 중복을 제거했다는 성과에 아직 하지 않은 목록 축소나 지연 표시의 이득을 합치지 않는다. 다음 판단의 비용과 대상별 동일한 표시 조건을 함께 검토해야 했다.
다른 사이트에는 코드와 검사 범위를 함께 넘긴다
새 단일 메뉴 모듈은 당시 선택을 발전시킨 코드이며 원본의 성능 수치를 재현했다고 주장하는 프로그램이 아니다. 대상 ID와 축별 위치, 저장 실패를 다루는 핵심 검사를 포함한 파일을 함께 공유한다. 새 모듈의 화면 조작 검수는 별도로 대기 중이다.
내가 다시 비교한다면 같은 데이터와 경로의 HTML, 출력한 목록 수, 이미지 태그, 선택과 스크롤 동작을 차례로 기록한다. 목록이 한 벌이라는 검사와 본문을 편하게 읽는 검사는 각각 필요하다. 나는 한 번의 감소 숫자보다 다음 제작자가 같은 조건에서 다시 확인할 수 있는 작업 기록을 남기고 싶다.