[WEB-010][실무] 웹페이지 로딩·반응·흔들림 측정하기
페이지 정보
본문
[이번 수업]
사용자가 느끼는 웹 성능을 Core Web Vitals로 나눕니다. 로딩, 입력 반응, 화면 안정성을 측정하고 지표별 개선 방향을 연결합니다.
[선수지식]
HTML·CSS·JavaScript와 브라우저 개발자 도구를 사용할 수 있어야 합니다. 밀리초는 1,000분의 1초입니다.
[학습목표]
1. LCP·INP·CLS의 뜻과 기준을 설명합니다.
2. 실험실 측정과 실제 사용자 측정을 구분합니다.
3. 지표별 개선 방법을 선택합니다.
[핵심개념]
LCP는 Largest Contentful Paint로 주요 콘텐츠가 그려지는 로딩 경험을 봅니다. INP는 Interaction to Next Paint로 클릭·키 입력 뒤 화면 갱신까지의 반응성을 평가합니다. CLS는 Cumulative Layout Shift로 예상하지 못한 화면 이동의 정도를 나타냅니다.
권장 기준은 LCP 2.5초 이하, INP 200밀리초 이하, CLS 0.1 이하입니다. 모바일과 데스크톱을 나누고 실제 방문의 75번째 백분위수를 봅니다. 이는 측정값을 작은 순서로 놓았을 때 75%가 포함되는 경계입니다. 한 번의 빠른 결과만으로 판단하지 않습니다.
실험실 데이터는 정해진 환경에서 반복해 수정 전후를 비교하기 좋습니다. 필드 데이터는 실제 기기·네트워크·행동을 반영합니다. 둘이 다르면 기간, 페이지, 기기 비율, 캐시 상태를 확인합니다. PerformanceObserver의 개별 항목은 진단용이며 완성된 필드 지표를 대신하지 않습니다.
LCP는 서버 응답, 핵심 이미지·글꼴의 발견 시점과 크기를 봅니다. INP는 긴 JavaScript 작업을 나누고 입력 직후 피드백을 보여 개선합니다. CLS는 이미지 영역의 크기를 미리 확보하고 기존 콘텐츠 위에 요소를 늦게 넣지 않아야 줄어듭니다. 하나씩 바꾸고 같은 조건에서 다시 측정합니다.
[따라하기]
다음을 index.html로 저장합니다. 외부 자원은 사용하지 않습니다.
```html
<!doctype html>
<html lang="ko">
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>웹 성능 관찰</title>
<style>
body { font: 16px sans-serif; max-width: 40rem; margin: 2rem auto; }
.hero { min-height: 8rem; padding: 1rem; background: #eef; }
button { padding: .7rem 1rem; }
</style>
<h1 class="hero">빠르고 안정적인 첫 화면</h1>
<button id="action">상태 바꾸기</button>
<output id="status">대기 중</output>
<pre id="metric">CLS(실습): 0.000</pre>
<script>
const metricBox = document.querySelector("#metric");
const actionButton = document.querySelector("#action");
const statusBox = document.querySelector("#status");
let cls = 0;
if (PerformanceObserver.supportedEntryTypes.includes("layout-shift")) {
new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
if (!entry.hadRecentInput) cls += entry.value;
}
metricBox.textContent = `CLS(실습): ${cls.toFixed(3)}`;
}).observe({ type: "layout-shift", buffered: true });
}
actionButton.addEventListener("click", () => { statusBox.textContent = "완료"; });
</script>
</html>
```
macOS/Linux는 `python3 -m http.server 8000 --bind 127.0.0.1`, Windows PowerShell은 `py -m http.server 8000 --bind 127.0.0.1`을 실행합니다. `http://127.0.0.1:8000`을 열면 예상 결과는 `CLS(실습): 0.000`과 버튼 클릭 뒤 `완료`입니다. 지원하지 않는 브라우저에서는 수치가 갱신되지 않을 수 있습니다.
[흔한 실수]
한 번의 점수나 평균만 보고 결론을 내리기 쉽습니다. 지표를 높이려고 중요한 콘텐츠를 숨기거나 접근성을 해치면 안 됩니다. 개발 환경과 실제 사용자 결과도 구분합니다.
[보안 주의]
서버는 `127.0.0.1`에만 연결합니다. 성능 로그에는 검색어, 토큰이 든 URL, 개인정보를 기록하지 말고 경로와 수치만 최소 수집합니다. 본인 소유의 로컬 또는 허가된 환경만 측정합니다.
[직접 해볼 과제]
1초 뒤 제목 위에 문단을 넣어 CLS 변화를 확인하세요. 다음에는 들어갈 높이를 미리 확보해 수치가 줄어드는지 비교하고 전후 값을 기록합니다.
[확인문제]
1. LCP, INP, CLS는 각각 어떤 경험을 측정하나요?
2. 실제 사용자 데이터에서 75번째 백분위수를 보는 이유는 무엇인가요?
3. 이미지 크기를 미리 확보하면 어떤 지표 개선에 도움이 되나요?
[다음 학습]
다음 과정 BACK-010에서는 파일 업로드·다운로드 보안을 배웁니다. WEB-011에서는 PWA를 다룹니다.
[공식 참고 자료]
- Core Web Vitals 공식 안내: https://web.dev/articles/vitals
- W3C Event Timing 명세: https://www.w3.org/TR/event-timing/
- Layout Instability 명세: https://wicg.github.io/layout-instability/
사용자가 느끼는 웹 성능을 Core Web Vitals로 나눕니다. 로딩, 입력 반응, 화면 안정성을 측정하고 지표별 개선 방향을 연결합니다.
[선수지식]
HTML·CSS·JavaScript와 브라우저 개발자 도구를 사용할 수 있어야 합니다. 밀리초는 1,000분의 1초입니다.
[학습목표]
1. LCP·INP·CLS의 뜻과 기준을 설명합니다.
2. 실험실 측정과 실제 사용자 측정을 구분합니다.
3. 지표별 개선 방법을 선택합니다.
[핵심개념]
LCP는 Largest Contentful Paint로 주요 콘텐츠가 그려지는 로딩 경험을 봅니다. INP는 Interaction to Next Paint로 클릭·키 입력 뒤 화면 갱신까지의 반응성을 평가합니다. CLS는 Cumulative Layout Shift로 예상하지 못한 화면 이동의 정도를 나타냅니다.
권장 기준은 LCP 2.5초 이하, INP 200밀리초 이하, CLS 0.1 이하입니다. 모바일과 데스크톱을 나누고 실제 방문의 75번째 백분위수를 봅니다. 이는 측정값을 작은 순서로 놓았을 때 75%가 포함되는 경계입니다. 한 번의 빠른 결과만으로 판단하지 않습니다.
실험실 데이터는 정해진 환경에서 반복해 수정 전후를 비교하기 좋습니다. 필드 데이터는 실제 기기·네트워크·행동을 반영합니다. 둘이 다르면 기간, 페이지, 기기 비율, 캐시 상태를 확인합니다. PerformanceObserver의 개별 항목은 진단용이며 완성된 필드 지표를 대신하지 않습니다.
LCP는 서버 응답, 핵심 이미지·글꼴의 발견 시점과 크기를 봅니다. INP는 긴 JavaScript 작업을 나누고 입력 직후 피드백을 보여 개선합니다. CLS는 이미지 영역의 크기를 미리 확보하고 기존 콘텐츠 위에 요소를 늦게 넣지 않아야 줄어듭니다. 하나씩 바꾸고 같은 조건에서 다시 측정합니다.
[따라하기]
다음을 index.html로 저장합니다. 외부 자원은 사용하지 않습니다.
```html
<!doctype html>
<html lang="ko">
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>웹 성능 관찰</title>
<style>
body { font: 16px sans-serif; max-width: 40rem; margin: 2rem auto; }
.hero { min-height: 8rem; padding: 1rem; background: #eef; }
button { padding: .7rem 1rem; }
</style>
<h1 class="hero">빠르고 안정적인 첫 화면</h1>
<button id="action">상태 바꾸기</button>
<output id="status">대기 중</output>
<pre id="metric">CLS(실습): 0.000</pre>
<script>
const metricBox = document.querySelector("#metric");
const actionButton = document.querySelector("#action");
const statusBox = document.querySelector("#status");
let cls = 0;
if (PerformanceObserver.supportedEntryTypes.includes("layout-shift")) {
new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
if (!entry.hadRecentInput) cls += entry.value;
}
metricBox.textContent = `CLS(실습): ${cls.toFixed(3)}`;
}).observe({ type: "layout-shift", buffered: true });
}
actionButton.addEventListener("click", () => { statusBox.textContent = "완료"; });
</script>
</html>
```
macOS/Linux는 `python3 -m http.server 8000 --bind 127.0.0.1`, Windows PowerShell은 `py -m http.server 8000 --bind 127.0.0.1`을 실행합니다. `http://127.0.0.1:8000`을 열면 예상 결과는 `CLS(실습): 0.000`과 버튼 클릭 뒤 `완료`입니다. 지원하지 않는 브라우저에서는 수치가 갱신되지 않을 수 있습니다.
[흔한 실수]
한 번의 점수나 평균만 보고 결론을 내리기 쉽습니다. 지표를 높이려고 중요한 콘텐츠를 숨기거나 접근성을 해치면 안 됩니다. 개발 환경과 실제 사용자 결과도 구분합니다.
[보안 주의]
서버는 `127.0.0.1`에만 연결합니다. 성능 로그에는 검색어, 토큰이 든 URL, 개인정보를 기록하지 말고 경로와 수치만 최소 수집합니다. 본인 소유의 로컬 또는 허가된 환경만 측정합니다.
[직접 해볼 과제]
1초 뒤 제목 위에 문단을 넣어 CLS 변화를 확인하세요. 다음에는 들어갈 높이를 미리 확보해 수치가 줄어드는지 비교하고 전후 값을 기록합니다.
[확인문제]
1. LCP, INP, CLS는 각각 어떤 경험을 측정하나요?
2. 실제 사용자 데이터에서 75번째 백분위수를 보는 이유는 무엇인가요?
3. 이미지 크기를 미리 확보하면 어떤 지표 개선에 도움이 되나요?
[다음 학습]
다음 과정 BACK-010에서는 파일 업로드·다운로드 보안을 배웁니다. WEB-011에서는 PWA를 다룹니다.
[공식 참고 자료]
- Core Web Vitals 공식 안내: https://web.dev/articles/vitals
- W3C Event Timing 명세: https://www.w3.org/TR/event-timing/
- Layout Instability 명세: https://wicg.github.io/layout-instability/
- 이전글[BACK-010][실무] 파일을 안전하게 받고 내려주기 26.09.04
- 다음글[JSTS-010][실무] 테스트·검사·코드 정리를 한 번에 실행하기 26.09.04
댓글목록
등록된 댓글이 없습니다.