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

점검 항목 · 성능

렌더링 차단 리소스 과다

파일이 몇 개냐보다 어디서 오느냐가 더 큽니다. 외부 도메인 하나가 늘 때마다 이름 조회와 연결이 처음부터 다시 시작됩니다.

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

01DEFINITION

한 줄로 말하면

문서 머리에 놓인 CSS 와 자바스크립트는 다 받아 오기 전까지 브라우저가 화면을 그리지 않습니다. 이런 파일이 여러 개이고 외부 도메인에서 온다면, 그 대기 시간이 그대로 흰 화면입니다. 당장 필요하지 않은 스크립트를 나중에 실행되도록 미루고 웹폰트 로딩 방식을 바꾸는 것만으로 첫 화면이 눈에 띄게 빨라집니다.

02RISK

없으면 무슨 일이 생기나

브라우저는 HTML 을 위에서부터 읽다가 스타일시트를 만나면 그 파일을 다 받을 때까지 화면을 그리지 않습니다. 스타일이 적용되지 않은 화면을 잠깐 보여 줬다가 바꾸면 더 나빠 보이기 때문입니다. 문제는 이런 파일이 대여섯 개일 때인데, 하나씩 순서대로 기다리는 동안 방문자는 흰 화면을 봅니다.

외부 도메인에서 받아 오면 비용이 훨씬 커집니다. 같은 서버에서 받는 파일은 이미 열린 연결을 재사용하지만, 다른 도메인은 이름 조회부터 연결과 암호화 협상까지 새로 해야 합니다. 파일 자체는 몇 KB 인데 그 앞의 준비 과정이 수백 밀리초 걸리는 일이 흔합니다.

웹폰트는 또 다른 방식으로 걸립니다. 폰트가 도착할 때까지 글자를 아예 그리지 않도록 동작하는 경우가 있어서, 배경과 이미지는 보이는데 글자만 없는 화면이 몇 초 이어집니다. 사람들은 이것을 로딩 실패로 받아들입니다.

03CHECK IT YOURSELF

직접 확인하는 방법

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

  1. 01
    머리에 무엇이 있는지 센다

    head 안의 스타일시트와 스크립트를 세어 봅니다. 스타일시트가 셋 이상이거나 스크립트가 지연 속성 없이 들어 있으면 이 항목을 살펴볼 때입니다.

    $ curl -s https://example.com/ \
      | sed -n '/<head/,/<\/head>/p' \
      | grep -cE '<link[^>]+stylesheet|<script[^>]+src'
  2. 02
    외부 도메인이 몇 개인지 본다

    개발자도구 네트워크 탭에서 도메인 기준으로 정렬하면 몇 곳에서 받아 오는지 보입니다. 첫 화면을 그리는 데 외부 도메인이 셋 이상 관여하면 개선 여지가 큽니다.

  3. 03
    지연 속성이 붙어 있는지 확인한다

    스크립트에 defer 나 async 가 없으면 그 스크립트는 화면 그리기를 멈춰 세웁니다. 특히 head 안에 있는 경우가 그렇습니다.

    $ curl -s https://example.com/ | grep -oE '<script[^>]+src="[^"]+"[^>]*>' | head -n 10
  4. 04
    글자가 언제 보이는지 관찰한다

    개발자도구에서 회선 속도를 낮추고 새로고침하면 배경만 보이고 글자가 없는 구간이 재현됩니다. 이 구간이 길면 웹폰트 설정을 손볼 때입니다.

04HOW TO FIX

고치는 방법

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

스크립트를 미룬다

대부분의 스크립트는 화면이 그려진 뒤에 실행돼도 됩니다. defer 를 붙이면 문서 순서를 지키면서 화면 그리기를 막지 않습니다. 서로 순서가 상관없는 것은 async 도 됩니다.

<script src="/js/site.js" defer></script>
<script src="https://analytics.example.com/tag.js" async></script>
스타일시트를 합치고 줄인다

여러 파일로 나뉜 스타일시트는 하나로 합치면 왕복 횟수가 줄어듭니다. 특정 화면에서만 쓰는 스타일은 그 화면에서만 불러오십시오.

웹폰트가 글자를 막지 않게 한다

이 한 줄이면 폰트가 도착하기 전에 기본 글꼴로 먼저 글자를 보여 줍니다. 폰트가 바뀌는 순간 살짝 흔들리지만, 글자가 없는 몇 초보다 낫습니다.

@font-face {
  font-family: "Pretendard";
  src: url("/fonts/Pretendard.woff2") format("woff2");
  font-display: swap;
}
외부 도메인에 미리 연결해 둔다

외부에서 받아 올 것이 있다면 연결 준비를 미리 시작하게 할 수 있습니다. 실제 요청이 나갈 때 이름 조회와 협상이 이미 끝나 있습니다. 다만 도메인 두세 개까지만 효과가 있습니다.

<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
첫 화면에 필요한 것만 남긴다

가장 확실한 개선은 지우는 것입니다. 예전에 붙였다가 쓰지 않는 슬라이더, 폰트 여러 벌, 채팅 위젯 두 개가 남아 있는 경우가 많습니다. 무엇을 미룰지 정하기 전에 무엇을 뺄 수 있는지부터 보십시오.

주의. 무료 스캔의 이 항목은 문서 머리에 있는 차단 리소스의 개수를 세는 간이 판정입니다. 실제로 화면이 언제 그려지는지를 재는 정밀 측정은 포함되지 않으므로, 개수가 적어도 특정 파일 하나가 매우 느리면 체감은 나쁠 수 있습니다.

05FAQ

자주 묻는 질문

defer 와 async 는 어떻게 다른가요

둘 다 화면 그리기를 막지 않습니다. 차이는 실행 시점입니다. defer 는 문서를 다 읽은 뒤 적힌 순서대로 실행하고, async 는 받는 대로 즉시 실행합니다. 스크립트끼리 순서가 중요하면 defer, 서로 독립적인 분석 도구 같은 것은 async 가 맞습니다.

스크립트를 body 끝으로 옮기는 것과 defer 는 같은 건가요

효과는 비슷하지만 defer 가 조금 낫습니다. body 끝에 두면 HTML 을 다 읽은 뒤에야 파일을 받기 시작하는데, head 에 defer 로 두면 받는 것은 일찍 시작하고 실행만 미룹니다. 다운로드와 실행을 분리할 수 있는 것이 차이입니다.

CSS 도 미룰 수 있나요

첫 화면에 필요한 CSS 는 미루면 안 됩니다. 스타일 없는 화면이 잠깐 보였다가 바뀌는 것이 더 나쁩니다. 다만 특정 화면에서만 쓰는 스타일이나 인쇄용 스타일은 조건을 붙여 나중에 받게 할 수 있습니다.

파일을 하나로 합치는 것이 지금도 유효한가요

예전만큼 절대적이지는 않습니다. 최신 프로토콜에서는 여러 파일을 동시에 받을 수 있어 개수의 부담이 줄었습니다. 다만 파일마다 압축 효율이 떨어지고 요청 처리 비용은 남아 있어서, 지나치게 잘게 쪼개는 것은 여전히 손해입니다.
여기까지는 항목 일반론입니다. 무엇이고 왜 문제이며 어떻게 고치는지는 감출 이유가 없어 그대로 적었습니다. 리포트에 들어가는 것은 귀사 사이트에서 실제로 어떤 값이 나왔는지 — 어느 주소의 어느 응답인지, 그 환경에서 어떤 순서로 적용해야 하는지, 예상 공수가 얼마인지입니다. 이 페이지만 보고 직접 고치셔도 되고, 실제로 그러시라고 적어 두었습니다.

GET STARTED

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

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