POC 계측 — 갈래 1·2 비교

페이지당 행 수 정본 — rowsPerPage.measured.ts

흔들리는 이유는 행 높이가 불규칙해서가 아니라 페이지마다 실리는 요소가 달라서다. 인사 표본은 결재선이 첫 장에만 붙고, 그룹이 끝나는 페이지에는 소계 행이 하나 더 들어가며, 행마다 주소 서브행이 붙어 데이터 한 행이 두 줄이라 한 줄짜리 소계가 남는 공간에 들어가기도 하고 안 들어가기도 한다. 그래서 설계 문서의 floor((용지높이 − 여백 − 머리글 − 바닥글) / 행높이) 로도,소계 행을 한 행으로 세고 라는 보완으로도 이 둘은 맞지 않는다.

다만 흔들림 자체가 서버 조판을 막지는 않는다(HDIT-3073 에서 확인). 세대차량은 18–21 로 흔들리면서도 서버 조판과 25칸 전부 일치한다. 페이지마다 실리는 요소가 달라 생기는 흔들림은 서버도 페이지마다 다시 계산하므로 따라간다. 따라가지 못하는 것은 인사 표본처럼 같은 소계 페이지가 20행을 담기도 하고 19행을 담기도 하는 경우이고, 그때는 행 높이가 행마다 다르다는 뜻이라 상수 모델로는 재현되지 않는다.

구간 기준선 — baseline.measured.ts

고사양 맥(15코어 32GB), localhost, 헤드리스 Chrome 152 에서 3회 측정한 중앙값이다. 저사양 수치가 아니고 구간 C 가 빠져 있다 — 헤드리스에는 인쇄 대화상자가 없다. 판정에 쓰려면 하한선 기기에서 위 실행부로 다시 재야 한다.

건수 램프 — server-once.measured.ts

마지막 칸은 갈래 1 이 같은 표본·건수에서 DOM 실측 분할에 쓴 시간이다 (paginateMs). 서버로 옮겨 없어지는 비용이 그 값이고, 그 자리에 들어오는 비용이 왼쪽의 서버 조판 시간이다. 둘 다 고사양 기기 수치이므로 저사양 판정에는 쓰지 않는다.

저사양 대리 측정 — CPU 4배 스로틀

민원일반 4,000건, 두 갈래를 번갈아 3회씩 돌린 중앙값이다. 하한선 기기가 없어 CPU 스로틀로 대신했고, 실제로 4.07배 느려진 것을 확인한 뒤 쟀다. 갈래 1 의 18 초 가운데 15.2 초가 DOM 실측 분할이다 — 서버로 옮기면 그 구간이 통째로 사라진다. 다만 스로틀 배수와 느려진 배수가 맞지 않으므로(강제 레이아웃이 섞여 있다) 이 비율을 실제 저사양 기기의 예측치로 쓰지 않는다.

한 방 상한 — 응답 5.72MiB 기준

다섯 표본 모두 응답이 먼저 막는다. 갈래 1 은 브라우저가 조판해 응답이 작으므로 반대로 요청이 먼저 막힌다 — amplifyLimits.measured.ts 의 값이 그것이다. 설계 문서의 비기능 요구인 4,000건은 다섯 표본 모두 한 응답에 들어간다. 응답 상한은 배포본 실측값이다(HDIT-2996). 막힐 때는 504 가 아니라 한 건 초과면 500, 크게 초과면 413 이 오므로 상태 코드만으로 요청 벽과 응답 벽을 가를 수 없다.