Week 6 · 완성도 다지기와 배포 Day 40 / 42

성능 최적화 실전 — Day 21 기준값과 비교하기

배포까지 끝난 지금, 그때 재둔 숫자와 지금을 나란히 놓아봅니다

그때는 뼈대, 지금은 살이 붙은 완성본

Day 21에서 측정했을 때는 사이트 뼈대만 있었지만, 지금은 Week 5의 fetch/API, 여러 페이지, 이미지가 잔뜩 붙은 완성본입니다. 기능이 늘어난 만큼 느려진 부분이 있는 게 당연합니다. 오늘은 그 차이를 숫자로 확인하고 원인을 짚어봅니다.

Day 21과 같은 도구(PageSpeed Insights)로 같은 페이지를 다시 측정해 표로 비교합니다. 이때 여러 지표를 종합해 매겨지는 0~100점 점수를 Performance 점수라고 부릅니다.

점수가 떨어졌다고 실패한 게 아닙니다. 기능이 늘었으니 자연스러운 변화이고, 오늘 할 일은 그 원인을 설명 가능한 상태로 만드는 것입니다.

Day 36의 width/height, lazy loading이 실제로 전부 적용됐는지 재확인

Pretendard 등 웹폰트 로딩이 텍스트 렌더링을 얼마나 지연시키는지 Network 탭에서 확인(Day 22)

Week 5에서 추가된 fetch 로직이 불필요하게 반복 실행되고 있지 않은지 점검

안 될 때 확인하세요 LCP(최대 콘텐츠 렌더링) 시간이 유독 길다면, 첫 화면에 보이는 이미지에 실수로 loading="lazy"가 붙어있지 않은지 Day 36 규칙을 다시 확인하세요.

1PageSpeed Insights로 재측정하고 위 비교표를 직접 채웁니다.

2가장 낮은 지표 하나를 골라 원인을 좁히고, 실제로 개선을 적용해봅니다.

AI에게 이렇게 지시해 보세요: "PageSpeed Insights 리포트에서 LCP가 3초로 나왔어. 이 페이지 코드를 보고 어떤 요소가 원인일 가능성이 높은지 짚어줘."

Day 21과 오늘의 성능 지표를 나란히 비교표로 정리했다.

가장 낮은 지표의 원인을 이미지/폰트/JS 중 하나로 좁혀봤다.

실제로 개선 하나를 적용하고 재측정으로 효과를 확인했다.

스스로 설명해보기 — 기능이 늘었는데 성능 점수가 떨어진 게 왜 실패가 아닌지 설명할 수 있나요?

LCP

Largest Contentful Paint. 화면에서 가장 큰 콘텐츠가 그려지는 데 걸린 시간

Performance 점수

PageSpeed Insights가 여러 지표를 종합해 매기는 0~100점 점수