본문 바로가기
MAKESITE
무료 스캔 문의하기 로그인

점검 항목 · 성능

초기 전송 용량 과다

이 항목의 좋은 점은 디자인을 한 픽셀도 건드리지 않고 고칠 수 있다는 것입니다. 보이는 그림은 그대로 두고 무게만 덜어냅니다.

심각도 보통 성능 무료 스캔 판정 항목 /check/page-weight

01DEFINITION

한 줄로 말하면

첫 화면을 그리는 데 필요한 전송량이 몇 MB 를 넘어가면, 이동 중 접속에서는 그것만으로 몇 초가 사라집니다. 대개 원본 그대로 올린 사진 몇 장이 전체의 대부분을 차지합니다. 사진을 최신 포맷으로 바꾸고 실제 표시되는 크기로 줄이는 것만으로 절반 이하가 되는 경우가 많고, 이 작업은 디자인을 한 픽셀도 건드리지 않습니다.

02RISK

없으면 무슨 일이 생기나

사무실 유선망에서는 이 문제가 보이지 않습니다. 5MB 짜리 페이지도 순식간에 열립니다. 문제는 지하철에서, 엘리베이터에서, 신호가 약한 실내에서 열 때입니다. 같은 페이지가 5초, 10초씩 걸리고 그동안 화면은 절반쯤 그려진 채로 멈춰 있습니다. 그리고 대부분의 방문이 그런 환경에서 일어납니다.

데이터 요금을 신경 쓰는 방문자도 있습니다. 페이지 하나를 여는 데 5MB 를 쓴다면, 사이트를 몇 페이지 둘러보는 것만으로 수십 MB 가 나갑니다. 소개 페이지 몇 장을 보는 데 그만큼 쓸 이유는 없습니다.

원인은 거의 항상 사진입니다. 스마트폰이나 DSLR 로 찍은 원본을 그대로 올리면 한 장이 3MB 를 넘고, 화면에서는 폭 400픽셀로 줄여 보여 줍니다. 즉 필요한 것의 스무 배를 보내고 브라우저가 줄이는 셈입니다. 스크립트와 CSS 가 아무리 커도 이것 하나에 미치지 못합니다.

03CHECK IT YOURSELF

직접 확인하는 방법

아래는 저희를 거치지 않고 지금 해 보실 수 있는 방법입니다. 결과를 저희에게 보내실 필요도 없습니다.

  1. 01
    개발자도구에서 총 전송량을 본다

    네트워크 탭 하단에 전송량과 리소스 개수가 나옵니다. 캐시를 비운 상태에서 새로고침해야 첫 방문자가 겪는 값이 나옵니다.

  2. 02
    무거운 것부터 정렬해서 본다

    크기순으로 정렬하면 상위 몇 개가 전체의 대부분을 차지하는 것이 보입니다. 이 상위 목록이 곧 작업 목록입니다. 전부 손대지 않아도 됩니다.

  3. 03
    이미지 하나의 실제 크기를 확인한다

    파일 용량과 함께 원본 픽셀 크기를 보십시오. 화면에서 400픽셀로 보이는데 원본이 4000픽셀이면 그만큼이 낭비입니다.

    $ curl -s -o /dev/null -w "%{size_download} bytes\n" \
        https://example.com/img/main-visual.jpg
    3874219 bytes
  4. 04
    느린 회선을 흉내 내 본다

    개발자도구의 네트워크 조절 기능으로 저속 환경을 선택하고 새로고침하십시오. 실제 방문자가 겪는 화면이 그대로 재현됩니다. 이것을 한 번 보면 우선순위가 달라집니다.

04HOW TO FIX

고치는 방법

서버 환경에 따라 적을 자리가 다릅니다. 아래는 가장 흔한 구성 기준이고, 적용 전에 현재 설정을 백업하십시오.

표시되는 크기로 줄인다

가장 효과가 크고 가장 쉽습니다. 화면에서 최대 800픽셀로 보이는 이미지는 800픽셀로 저장합니다. 고해상도 화면을 고려해도 두 배면 충분합니다.

최신 형식으로 바꾼다

같은 화질에서 파일 크기가 크게 줄어듭니다. 예전 브라우저를 위해 원본을 함께 두고 브라우저가 고르게 하면 안전합니다.

<picture>
  <source srcset="/img/visual.webp" type="image/webp">
  <img src="/img/visual.jpg" alt="생산 라인" width="800" height="450">
</picture>
첫 화면에 없는 이미지는 나중에 받는다

스크롤해야 보이는 이미지를 처음부터 받을 이유가 없습니다. 속성 하나면 됩니다. 다만 첫 화면에 보이는 이미지에는 붙이지 마십시오. 오히려 늦게 뜹니다.

<img src="/img/gallery-07.jpg" loading="lazy" alt="제품 상세" width="600" height="400">
폭과 높이를 반드시 적는다

용량과는 별개지만 같이 해야 하는 일입니다. 크기를 적지 않으면 이미지가 도착할 때마다 아래 내용이 밀려 내려가고, 읽던 사람이 버튼을 잘못 누릅니다.

쓰지 않는 것을 걷어낸다

예전에 붙였다가 안 쓰는 슬라이더, 아이콘 폰트 전체, 여러 개의 자바스크립트 라이브러리가 남아 있는 경우가 많습니다. 네트워크 탭 목록을 하나씩 짚어 보면 정체를 모르는 파일이 나옵니다.

주의. 이미지를 줄여도 TTFB 는 줄지 않습니다. 첫 응답이 느린 것과 전송량이 많은 것은 다른 문제이고, 둘 다 걸려 있다면 순서는 첫 응답이 먼저입니다. 화면이 그려지기 시작하는 시점 자체가 밀려 있는 상태에서는 이미지 작업의 효과가 보이지 않습니다.

05FAQ

자주 묻는 질문

몇 MB 부터 문제인가요

첫 화면 기준 2MB 를 넘으면 살펴볼 때이고 5MB 를 넘으면 확실히 무겁습니다. 다만 절대 기준보다는 구성이 중요합니다. 상품 사진이 많은 쇼핑몰은 무거울 수밖에 없고, 그 경우 첫 화면에 필요한 것만 먼저 받게 하는 쪽으로 접근합니다.

이미지 화질이 떨어지지 않나요

표시되는 크기로 줄이는 것은 화질 손실이 아니라 낭비 제거입니다. 화면에서 800픽셀로 보이는 이미지를 800픽셀로 저장하면 눈에 보이는 차이가 없습니다. 최신 형식으로 바꾸는 것도 같은 화질에서 용량만 줄이는 방식입니다.

CDN 을 쓰면 용량 문제가 해결되나요

CDN 은 파일을 가까운 곳에서 보내 줄 뿐 크기를 줄이지는 않습니다. 3MB 는 여전히 3MB 입니다. 다만 이미지 변환 기능을 제공하는 CDN 을 쓰면 요청할 때 크기와 형식을 바꿔 주므로, 원본을 그대로 두고도 효과를 볼 수 있습니다.

동영상 배경은 어떤가요

가장 무거운 요소입니다. 첫 화면에 자동 재생 동영상을 두면 그것만으로 수 MB 가 나갑니다. 정말 필요하다면 첫 프레임을 이미지로 먼저 보여 주고 동영상은 나중에 받게 하십시오. 모바일에서는 아예 재생하지 않는 선택도 흔합니다.
여기까지는 항목 일반론입니다. 무엇이고 왜 문제이며 어떻게 고치는지는 감출 이유가 없어 그대로 적었습니다. 리포트에 들어가는 것은 귀사 사이트에서 실제로 어떤 값이 나왔는지 — 어느 주소의 어느 응답인지, 그 환경에서 어떤 순서로 적용해야 하는지, 예상 공수가 얼마인지입니다. 이 페이지만 보고 직접 고치셔도 되고, 실제로 그러시라고 적어 두었습니다.

GET STARTED

내 사이트는
이 항목을 통과할까요

주소만 넣으시면 이 항목을 포함해 25가지를 판정해 점수와 실패 개수를 보여 드립니다. 로그인도, 소유 확인도 필요 없습니다 — 전부 밖에서 관찰만 하는 항목이기 때문입니다.