사이트가 늦게 열린다는 이야기를 들으면 사진을 모두 줄이거나 호스팅을 바꾸는 방법부터 생각하기 쉽습니다. 하지만 첫 응답을 기다리는 경우와 이미지가 늦게 나타나는 경우, 버튼이 반응하지 않는 경우는 원인이 다를 수 있습니다. 먼저 어디에서 기다림이 생기는지 기록하고, 필요한 기능을 유지하면서 수정할 범위를 정해 보세요. 이번 글은 운영자가 제작 담당자와 점검 순서를 정할 때 사용할 수 있는 안내입니다.
1. 먼저 느린 페이지와 측정 조건을 기록하세요
홈페이지 속도 개선을 시작할 때는 사이트 전체가 느리다는 인상보다 어떤 주소에서 어떤 기다림이 발생하는지 확인하는 것이 좋습니다. 메인 화면, 서비스 안내, 문의 페이지를 나눠 PageSpeed Insights로 살펴보고 모바일과 데스크톱 결과를 함께 기록하세요. 화면이 처음 나타날 때 느린지, 내용을 누른 뒤 반응이 늦는지도 구분해 두면 담당자가 원인을 좁히기 쉽습니다.
Google은 실제 사용자 데이터와 실험실 진단을 구분해 제공합니다. 실제 사용자 자료는 최근 28일의 수집 기간을 반영하며 표본이 부족하면 표시되지 않을 수 있습니다. 데이터가 없다는 표시를 곧바로 오류로 해석하지 마세요. 페이지 주소와 측정 날짜, 기기 조건을 남기고 동일한 조건에서 비교해야 변경 전후를 판단하는 데 도움이 됩니다.
근거 자료: Google — PageSpeed Insights 안내
2. 첫 화면의 큰 콘텐츠가 언제 보이는지 살펴보세요
홈페이지 속도 개선에서 첫 화면의 대표 이미지나 큰 제목은 우선 확인할 대상입니다. LCP는 화면 안의 가장 큰 이미지 또는 텍스트 블록이 표시되는 시점을 살피는 지표입니다. 점수가 낮다는 이유만으로 모든 사진을 줄이기보다 실제로 어떤 요소가 측정 대상인지 먼저 확인하세요. 같은 페이지라도 화면 크기에 따라 중요한 요소가 달라질 수 있습니다.
web.dev의 LCP 안내는 서버 응답부터 리소스 발견, 다운로드, 화면 표시까지 이어지는 과정을 나눠 설명합니다. 예를 들어 이미지는 작아도 늦게 발견되거나 화면에 표시되기까지 기다리면 개선 여지가 남습니다. 대표 이미지가 필요한데도 로딩 순서에서 뒤로 밀려 있는지 개발 담당자와 확인하세요. 이 글의 순서는 점검을 위한 안내이며 모든 사이트에 같은 수정 효과를 보장하는 공식은 아닙니다.
근거 자료: web.dev — LCP 최적화
3. 표시 크기에 맞는 이미지 파일을 준비하세요
홈페이지 속도 개선을 위한 이미지 최적화는 사진을 무조건 흐리게 만드는 작업이 아닙니다. 실제 화면에 표시되는 크기와 기기의 픽셀 밀도를 고려하고, 원본보다 작은 여러 크기의 파일을 제공하는 방법을 검토하세요. 작은 카드에 매우 큰 원본 사진을 그대로 쓰고 있다면 불필요한 데이터를 보내고 있을 수 있습니다.
web.dev는 srcset과 sizes를 이용해 브라우저가 적절한 이미지 후보를 선택하도록 구성하는 방법을 설명합니다. WebP나 AVIF 같은 형식도 비교할 수 있지만 용량 감소 폭은 이미지와 설정에 따라 달라집니다. 변환 뒤에는 글자가 들어간 사진의 가장자리, 상품의 질감, 투명 배경이 망가지지 않았는지 직접 확인하세요. 파일 이름만 바꾸는 것은 형식 변환이 아니며, 중요한 원본은 별도로 보관하는 편이 좋습니다.
근거 자료: web.dev — 이미지 성능
4. 아래쪽 이미지는 필요한 시점에 불러오세요
홈페이지 속도 개선을 하면서 지연 로딩을 모든 이미지에 똑같이 적용하지는 마세요. 아직 화면 밖에 있는 이미지를 나중에 불러오면 초기 요청을 줄이는 데 도움이 될 수 있습니다. 그러나 처음부터 보여야 하는 대표 이미지까지 늦추면 방문자가 가장 먼저 봐야 할 콘텐츠의 표시가 지연될 수 있습니다.
web.dev는 첫 화면에 보이는 이미지, 특히 LCP 이미지에는 지연 로딩을 적용하지 않도록 안내합니다. 본문 아래쪽의 사진처럼 스크롤 후 나타나는 콘텐츠와 첫 화면의 이미지를 구분해 설정하세요. 이미지의 가로·세로 크기나 비율도 미리 확보해 두면 로딩 중 주변 내용이 갑자기 밀리는 문제를 줄이는 데 도움이 됩니다. 적용 후에는 빠르게 스크롤할 때 이미지가 적절한 시점에 나타나는지도 살펴보세요.
근거 자료: web.dev — 이미지 지연 로딩
5. 외부 기능과 스크립트의 역할을 확인하세요
홈페이지 속도 개선이 필요하다면 채팅창, 지도, 동영상, 광고와 분석 도구 등 외부 스크립트 목록도 살펴보세요. 각각은 필요한 기능일 수 있지만 추가 요청과 실행 작업을 발생시킵니다. 현재 사용하는 기능인지, 같은 역할의 도구가 중복 설치됐는지 운영 담당자와 확인한 뒤 조정 범위를 정하는 것이 좋습니다.
web.dev는 외부 JavaScript가 다운로드와 실행 비용을 더할 수 있다고 설명합니다. 화면에서 보이지 않는다고 곧바로 삭제하면 문의 접수나 방문 측정이 끊길 수 있으므로 목적과 담당자를 먼저 기록하세요. 꼭 필요한 기능이라면 실행 시점이나 사용자 동작 뒤에 불러오는 방식을 검토할 수 있습니다. 한꺼번에 여러 도구를 제거하기보다 변경한 항목을 기록하고 그 기능이 유지되는지 확인하면서 진행합니다.
근거 자료: web.dev — 외부 JavaScript 로딩
6. 서버 응답과 캐시는 별도로 점검하세요
홈페이지 속도 개선은 이미지나 화면 코드만으로 끝나지 않을 수 있습니다. 서버 응답 시간이 길면 브라우저가 첫 데이터를 받기 전부터 기다리게 됩니다. web.dev의 TTFB 안내는 응답 지연과 여러 단계의 리디렉션 등을 점검할 대상으로 설명합니다. 여러 주소를 거쳐 최종 화면으로 이동한다면 직접 관리할 수 있는 불필요한 경로부터 확인하세요.
브라우저 캐시와 서버 쪽 캐시도 구분해 살펴봅니다. 변경이 드문 파일을 재사용하면 반복 다운로드를 줄이는 데 도움이 되지만, 모든 응답을 같은 방식으로 캐시해서는 안 됩니다. 문의 접수 결과나 개인별 내용은 공개 자산과 다른 정책이 필요합니다. 캐시를 조정한 뒤 새 이미지와 원고가 제대로 갱신되는지, 처음 방문한 경우와 다시 방문한 경우의 차이가 어떤지도 함께 확인하세요.
근거 자료: web.dev — 첫 바이트 응답 시간 개선 · web.dev — HTTP 캐시
7. 같은 조건으로 다시 측정하고 기능을 확인하세요
홈페이지 속도 개선의 마지막 단계는 변경 내용을 기록하고 다시 확인하는 것입니다. 같은 주소와 기기 조건에서 여러 번 측정해 경향을 살펴보세요. 네트워크와 실행 환경 때문에 결과가 달라질 수 있으므로 한 번의 점수 차이만으로 결론을 내리지 않는 것이 좋습니다. 실제 사용자 자료는 수집 기간을 포함하므로 수정 직후 결과와 동일하게 움직이지 않을 수 있습니다.
속도 수치와 함께 메뉴 이동, 문의 입력, 접수 완료, 전화와 카카오톡 연결 등 주요 행동을 따라가 보세요. 필수 기능을 없애 점수가 높아졌다면 운영 목적을 달성했다고 보기 어렵습니다. 수정 전의 불편, 바꾼 항목, 측정 조건, 다시 확인한 결과를 한 표에 남겨두면 이후 담당자가 바뀌어도 판단 근거를 이어갈 수 있습니다. 개선 작업은 방문자가 내용을 읽고 필요한 일을 마치는 경험을 기준으로 정리하세요.
근거 자료: Google — PageSpeed Insights 안내
제작 문의 전에 준비할 것
작업을 문의하실 때에는 느리다고 느낀 페이지 주소, 주로 이용하는 기기, 문제가 발생하는 상황과 측정 결과를 함께 준비해 주세요. Gnosislab design은 현재 구성과 꼭 유지해야 하는 기능을 확인해 수정 범위를 구체화합니다. 중요한 서비스 화면부터 기준을 남기고 한 단계씩 확인하면, 막연한 체감 대신 확인 가능한 기록으로 다음 작업을 논의할 수 있습니다.