"사이트가 좀 느린 것 같은데 서버를 올려야 할까요." 이 질문을 받으면 서버부터 보지 않습니다. 대부분의 경우 서버는 빠른데 브라우저가 내려받을 것이 너무 많아서 느립니다. 최근 저희 사이트를 점검하면서 확인한 내용을 그대로 정리했습니다.
먼저 재고, 그다음에 고친다
점검을 시작할 때 확인하는 숫자는 두 개입니다.
- 서버가 첫 응답을 주기까지 걸린 시간(TTFB). 이것이 길면 서버나 데이터베이스 문제입니다.
- 브라우저가 내려받은 총량과 요청 수. TTFB 가 짧은데 느리다면 원인은 여기 있습니다.
저희 사이트는 TTFB 가 60~95ms 였습니다. 서버는 문제가 아니었다는 뜻입니다. 그래서 내려받는 양을 종류별로 나눠 봤습니다.
포트폴리오 페이지가 2.2MB 였고 그중 이미지가 82%였습니다. 특히 파일 하나가 1,612KB로 페이지 전체의 73%를 차지했습니다. 화면에는 354px 크기로 보이는 썸네일인데, 원본이 2,598px 짜리 PNG 였습니다. 구 사이트에서 넘어온 파일이라 지금의 업로드 규칙을 거치지 않은 것이었습니다.
느린 사이트의 원인은 여러 곳에 조금씩 퍼져 있기보다, 한두 가지에 몰려 있는 경우가 훨씬 많습니다. 그래서 전부 손보기 전에 재보는 것이 먼저입니다. 재보지 않고 최적화하면 효과 없는 곳에 시간을 씁니다.
고친 것은 세 가지뿐
1. 응답 압축이 꺼져 있었다
HTML·CSS·JS 가 압축 없이 그대로 전송되고 있었습니다. 텍스트 파일은 보통
70~80% 줄어드는데, 이 설정이 빠져 있으면 그 이득을 통째로 놓칩니다.
확인하는 방법은 간단합니다. 브라우저 개발자 도구의 네트워크 탭에서
응답 헤더에 Content-Encoding 이 있는지 보면 됩니다.
2. 옛 이미지가 원본 그대로 남아 있었다
지금은 업로드하면 자동으로 WebP 로 바꾸고 용도별 최대 폭으로 줄입니다. 문제는 그 규칙이 생기기 전에 올라온 파일들이었습니다. 같은 규칙을 옛 파일에 적용하고 데이터베이스의 주소도 함께 바꿨습니다.
3. 폰트 선언 파일이 첫 화면을 막고 있었다
한글 웹폰트는 글자 범위별로 파일이 나뉘어 있어 선언만 담은 CSS 가 커집니다.
저희는 48KB 였는데, 이 파일이 화면을 그리기 전에 반드시 받아야 하는
자원으로 걸려 있었습니다. 실제로는 화면 배치에 필요한 규칙이 없고
모든 선언이 font-display: swap 이라, 늦게 와도 시스템 폰트로 먼저
그려진 뒤 교체될 뿐입니다. 그래서 화면을 막지 않도록 바꿨습니다.
결과
느린 회선(4G 근사, 지연 80ms)에서 캐시 없이 처음 열었을 때 걸린 시간입니다.
포트폴리오 페이지가 5.1초에서 0.7초가 됐습니다. 새로 만든 것은 없습니다. 이미 있던 것을 제대로 쓰게 했을 뿐입니다. 홈은 1.97초에서 1.74초로 개선폭이 작은데, 이 페이지에는 큰 이미지가 없어서 줄일 것이 애초에 적었기 때문입니다. 페이지마다 원인이 다르다는 뜻이기도 합니다.
스켈레톤 화면은 답이 아닐 수 있다
로딩이 느릴 때 "빈 자리에 회색 상자를 먼저 보여주자"는 제안이 자주 나옵니다. 화면을 브라우저에서 조립하는 방식이라면 맞는 처방입니다. 하지만 서버가 완성된 화면을 보내는 방식이라면 반대 효과가 납니다. 글자와 배치가 이미 첫 응답에 들어 있는데, 그것을 일부러 가렸다가 보여주는 셈이기 때문입니다.
대신 이런 것들은 확실히 효과가 있습니다.
- 화면 밖 이미지는 나중에 받기. 스크롤해야 보이는 이미지를 처음부터 받을 이유가 없습니다.
- 이미지마다 크기를 지정하기. 자리를 미리 잡아두면 이미지가 늦게 와도 글이 밀리지 않습니다. 읽는 중에 화면이 튀는 현상이 사라집니다.
- 첫 화면에 보이는 이미지는 먼저 받기. 나머지와 반대로 우선순위를 올려야 합니다.
재방문은 이미 빠를 수 있다
여기까지가 첫 방문 이야기입니다. 두 번째 방문부터는 브라우저가 파일을 저장해 두기 때문에 훨씬 빠릅니다. 그래서 "제 컴퓨터에서는 빠른데요"라는 말이 자주 나옵니다. 만든 사람은 늘 재방문 상태이기 때문입니다.
확인하려면 브라우저의 시크릿 창을 쓰거나 개발자 도구에서 캐시를 끄고 측정하십시오. 처음 오는 사람이 보는 화면이 실제 성능입니다.
점검할 때 보는 순서
- TTFB 가 긴가. 길면 서버·데이터베이스, 짧으면 전송량 문제입니다.
- 가장 큰 파일 세 개가 무엇인가. 대부분 여기서 원인이 드러납니다.
- 압축이 켜져 있는가. 설정 하나로 텍스트 자원이 크게 줄어듭니다.
- 화면을 막는 자원이 몇 개인가. 첫 화면에 필요 없는 것이 섞여 있는 경우가 많습니다.
속도 개선은 큰 공사가 필요한 일이 아닌 경우가 많습니다. 어디가 무거운지만 정확히 알면 대부분은 설정으로 끝납니다.
