홈페이지가 느릴 때 확인할 이미지·폰트·스크립트

홈페이지가 늦게 뜨거나 버튼 반응이 느리면 어느 파일과 동작에서 시간이 걸리는지 확인합니다. 이미지·폰트·스크립트는 자주 살펴보는 항목이지만, 측정 없이 원인을 확정하지 않습니다. 속도 개선을 매출 증가나 검색 순위 상승으로 바로 환산하지도 않습니다.

먼저 대표 페이지를 측정합니다

회사 소개·서비스·사례·문의 등 대표 페이지 3~5개를 정하고 모바일과 PC의 조건을 기록합니다. web.dev의 코어 웹 바이탈 설명을 참고해 LCP(주요 콘텐츠 로딩), INP(입력 반응), CLS(레이아웃 이동)를 확인합니다.

2026년 7월 원고에서 참고한 양호 기준은 LCP 2.5초 이내, INP 200ms 이내, CLS 0.1 이하입니다. 현재 기준과 측정 방식은 공식 안내를 다시 확인합니다. 실제 방문자 자료와 실험실 측정값을 혼합하지 않습니다.

화면에서 400px로 표시하는 썸네일에 3000px 원본을 사용하는지 확인합니다. 필요한 크기로 줄이고 WebP·AVIF 등 후보 형식의 용량과 화질을 비교합니다. 형식만 바꿨다고 일정 비율로 줄어든다고 약속하지 않습니다.

첫 화면의 주요 이미지는 로딩을 불필요하게 늦추지 않습니다. 화면 밖 이미지는 지연 로딩을 검토하고, 이미지 영역의 크기를 미리 확보해 로딩 중 글과 버튼이 밀리지 않게 합니다. 변경 후 흐려진 글자나 잘린 이미지가 없는지도 봅니다.

사용하지 않는 굵기와 폰트 파일이 로딩되는지 확인합니다. 일부 글자만 포함한 폰트 파일을 쓴다면 본문·고객명·다국어에서 글자가 빠지지 않는지 검사합니다. 두 굵기만으로 충분한 사이트도 있지만 디자인과 본문의 필요에 따라 결정합니다.

font-display: swap 등으로 글자가 늦게 표시되는 상황을 줄일 수 있으나, 대체 폰트에서 바뀔 때 줄바꿈과 화면 이동도 확인해야 합니다. 읽기 쉬운 크기와 대비는 KRDS와 WCAG를 참고합니다.

채팅·분석·슬라이더 등 외부 기능을 목록으로 만들고 실제 사용하는지 확인합니다. 중복된 분석 태그가 있다면 집계 방식과 동의 조건을 함께 점검합니다. 태그매니저로 옮기는 것만으로 중복이나 속도 문제가 해결되는 것은 아닙니다.

defer나 async는 실행 순서에 영향을 주므로 기능 간 의존성을 확인해 적용합니다. 문의·동의·분석 기능을 속도만 보고 삭제하거나 실행 시점을 바꾸지 않습니다. 본문이 전달되는 방식은 홈페이지 구조 점검에서 다룹니다.

이미지·폰트·스크립트 중 바꾼 항목과 날짜를 남기고 같은 페이지를 다시 측정합니다. 실제 휴대폰에서도 글자 표시, 메뉴, 버튼, 문의 폼이 정상인지 확인합니다. 콘텐츠나 외부 기능을 추가한 뒤에는 주요 화면을 다시 점검합니다.