홈페이지가 느릴 때, 서버부터 바꿔야 할까

"홈페이지가 좀 느린 것 같다"는 말을 들으면 서버를 올리거나 호스팅을 옮기자는 얘기가 먼저 나오곤 해요. 그런데 페이지가 늦게 뜨는 이유는 서버가 첫 응답을 늦게 주는 경우, 큰 이미지나 글꼴을 받느라 늦는 경우, 외부 스크립트가 화면을 붙잡는 경우로 나뉘고, 서버를 바꿔서 바로 빨라지는 건 주로 첫 번째예요. 어느 쪽인지는 구글의 무료 측정 도구 페이지스피드 인사이트로 가려 볼 수 있는데, 우리 홈페이지 주소를 넣어 결과를 띄워 두고 읽으면 화면과 맞춰 보기 편해요.

화면이 뜨기까지의 시간은 네 토막으로 나뉘어요

방문자가 "느리다"고 느끼는 순간은 대개 화면에서 가장 큰 덩어리, 그러니까 첫 화면의 큰 사진이나 큰 제목이 뜨기까지예요. 구글은 이 시간을 LCP(가장 큰 콘텐츠가 그려지는 시간)라고 부르고, 2.5초 안이면 좋다고 봅니다.

web.dev 의 LCP 안내는 이 2.5초를 네 토막으로 나눠요.

서버 사양이 그대로 드러나는 건 첫 토막이에요. 나머지 셋은 주로 사진 크기, 사진을 부르는 순서, 그리기를 막는 스크립트에 달려 있다 보니, 이쪽이 길면 서버만 더 좋은 것으로 바꿔서는 크게 달라지지 않는 경우가 많아요. 다만 사진도 서버나 전송망을 거쳐 내려오기 때문에, 사진 받는 시간에는 서버의 전송 속도와 캐시 설정도 섞여 있습니다.

페이지스피드 인사이트로 실제 방문자 기록부터 봐요

페이지스피드 인사이트에 주소를 넣으면 결과가 두 단으로 나오는데, 위쪽은 크롬을 쓰는 실제 방문자가 지난 28일 동안 겪은 기록이고, 아래쪽은 구글이 중간급 휴대폰과 모바일 통신을 흉내 내 한 번 띄워 본 결과예요. 아래쪽에 나오는 0~100점 성능 점수는 실험실 측정이라 할 때마다 조금씩 달라집니다.

방문자가 실제로 겪은 건 위쪽이니까 그쪽을 먼저 봅니다. 여기 나오는 LCP 는 방문자 넷 중 셋이 이보다 빨랐던 값인데, 이게 2.5초를 넘으면 실제로 느린 거예요. 같은 칸에 누른 뒤 반응하기까지의 시간(INP, 200밀리초 이하가 좋음)과 화면이 갑자기 밀리는 정도(CLS, 0.1 이하가 좋음)도 함께 나오는데, "느리다"는 말이 버튼을 눌러도 반응이 늦다는 뜻일 때도 있으니 셋을 같이 봐야 해요. 세 값이 모두 '좋음'이면 아래 점수가 낮아도 급한 문제는 아닌 편입니다. 방문자가 적은 사이트는 그 페이지만의 기록이 모자라 사이트의 모든 페이지를 합친 값이 대신 나오거나 아예 비어 있기도 한데, 그때는 아래 실험실 결과로 원인을 찾으면 됩니다.

'LCP 분석'의 첫 바이트가 0.8초 이하라면 다른 토막부터 봐요

실험실 결과 아래 '인사이트' 목록에서 'LCP 분석'을 펼치면 앞의 네 토막이 각각 몇 초였는지 나와요. 도구 버전에 따라 이름은 조금 다를 수 있지만, 여기서 '첫 바이트까지의 시간'을 보면 됩니다.

구글 web.dev 는 첫 바이트까지 0.8초 이하면 좋고 1.8초를 넘으면 나쁘다고 봐요. 첫 바이트가 0.8초 안에 들어오는데 LCP 가 4초라면, 남은 3초 넘는 시간은 사진을 받거나 글꼴·스크립트를 기다리며 화면에 그리는 데 쓰인 거라, 서버를 바꾸기 전에 그 토막들을 먼저 보는 게 순서예요. 사진이 이미 충분히 가벼운데도 '리소스 로드 시간'만 유독 길다면, 그때는 사진을 내려보내는 서버나 전송망의 속도도 의심해 볼 만합니다. 반대로 여러 번 재도 1.8초를 넘는다면 서버 쪽을 들여다볼 이유가 생기고, 그 사이라면 다른 토막 중 더 긴 쪽부터 손보는 게 순서입니다.

첫 바이트가 느리다고 해서 곧바로 서버 사양이 문제인 것도 아닌데, 이 시간에는 주소가 다른 주소로 한 번 더 넘어가는 시간(리디렉션)과 서버와 연결을 맺는 시간이 같이 들어 있거든요. 'http' 로 들어온 방문자를 'https' 로, 'www' 없는 주소를 'www' 주소로 두세 번 넘기고 있다면 그것만 정리해도 줄어들 수 있습니다.

이미지와 외부 스크립트는 따로 이름이 붙어 나와요

첫 바이트가 괜찮은데도 느리다면 같은 인사이트 목록에서 두 항목을 보면 돼요. '이미지 전송 개선'은 화면에 보이는 크기보다 훨씬 큰 사진을 받고 있거나 더 가벼운 형식으로 바꿀 수 있는 사진을 줄 세워 보여 줍니다. 첫 화면에 큰 슬라이드 사진이나 배경 영상을 둔 사이트라면 여기서 줄일 수 있는 대기 시간이 큰 편이에요.

'서드 파티'는 우리 사이트가 아닌 곳에서 불러오는 코드, 그러니까 채팅 상담 창, 광고·방문 분석 태그, 지도, 영상 삽입 같은 것들이 얼마나 시간을 쓰는지 보여 줘요. web.dev 는 코드를 최적화했는데도 느리다면 외부 스크립트 탓인 경우가 많다고 적고 있습니다. 마케팅 도구를 하나씩 붙이다 보면 이런 코드가 쌓이는데, 이 목록에 회사 이름별로 나오니까 지금 쓰지 않는 서비스가 보이면 제작사에 빼 달라고 하면 됩니다.

측정 결과를 들고 제작사에 물어보면 돼요

서버 이전이나 업그레이드 견적을 받았다면, 페이지스피드 인사이트 결과 화면을 캡처해 이렇게 물어보면 그 견적이 필요한지 판단할 근거가 생겨요.

홈페이지 속도를 측정한 결과를 첨부합니다. 서버를 바꾸면 이 중 어느 시간이 얼마나 줄어드는지, 이미지나 외부 서비스를 먼저 정리해서 해결할 수 있는지 설명 부탁드립니다.

숫자를 직접 찾기 어렵다면 'LCP 분석'을 펼친 화면만 캡처해 붙여도 돼요.

고친 뒤에는 같은 도구로 다시 재면 되는데, 위쪽 실제 방문자 기록은 지난 28일을 모은 값이라 바뀐 결과가 다 반영되려면 4주쯤 걸립니다.

측정 결과를 읽기 어렵거나 받은 견적이 맞는지 따로 확인받고 싶다면 웨이비웍스에 문의하실 수 있어요. 결과 화면을 보내 주시면 어디서 시간이 걸리는지 같이 봐 드려요.