스크립트·스타일 로딩 순서와 점진적 렌더링

왜 로딩 순서가 중요한가

브라우저는 HTML을 위에서 아래로 파싱하며 DOM을 만들고, 그 사이에 만난 CSS와 스크립트를 내려받는다. CSS는 렌더링을, 일반 스크립트는 파싱을 막는다. 어떤 자원을 어디에 어떤 속성으로 두느냐에 따라 첫 화면이 뜨는 시간과 스크립트가 DOM을 볼 수 있는 시점이 달라진다. 파서가 왜 멈추는지, DOM·CSSOM·렌더 트리가 어떻게 만들어지는지는 브라우저 렌더링 과정에 있다.

script, async, defer, module

<script>          파싱 ──■ 받기 ■ 실행 ■── 파싱 계속
<script async>    파싱 ──────────■ 실행 ■── 파싱 계속
                  받기 ═════════╝            (받는 대로 바로 실행)
<script defer>    파싱 ─────────────────────── 파싱 끝 ■ 실행
                  받기 ═══════╝                (문서 순서대로)

알아 둘 규칙:

• async와 defer는 src가 있는 클래식 스크립트에만 효과가 있다. 인라인 클래식 스크립트에서는 무시된다. 모듈 스크립트는 인라인이어도 async가 먹는다.
• 둘 다 붙이면 async로 동작한다.
• defer 스크립트는 DOMContentLoaded를 늦춘다. async 스크립트는 그 이벤트와 순서가 정해져 있지 않다.
• 모듈은 defer가 기본이라 defer를 따로 붙여도 변화가 없다. 다른 출처의 모듈은 CORS 응답이 필요하다(→ 모듈: export와 import).
• 비동기 스크립트의 document.write()는 무시된다. document.write()는 동기 파싱을 전제로 한 옛 API라 쓰지 않는다.
• JS로 만들어 DOM에 넣은 <script>(document.createElement('script'))는 문서에 붙는 순간 받기 시작하고 async처럼 동작한다. 아무것도 기다리지 않고 아무도 기다리지 않으며, 먼저 받은 것부터 실행된다(load-first). 넣은 순서대로 실행해야 하면 붙이기 전에 script.async = false를 준다. 로딩 성공·실패는 load·error 이벤트로 안다(페이지 생명주기와 리소스 로딩 이벤트).
• defer 스크립트끼리는 작은 파일이 먼저 받아져도 문서 순서대로 실행된다. async는 다운로드가 끝난 순서다.
• 파서를 막는 스크립트는 그보다 앞서 요청된 렌더링 차단 CSS가 도착해 파싱될 때까지 실행을 기다린다. 스크립트가 getComputedStyle()처럼 스타일을 읽을 수 있기 때문이다.

프리로드 스캐너가 못 보는 자원

파서가 스크립트나 CSS에 막혀 있는 동안에도 프리로드 스캐너(보조 파서)가 받은 HTML 원문을 훑어 이미지·CSS·JS를 미리 요청한다. 그래서 중요한 자원은 서버가 보낸 HTML 마크업 안에 있어야 한다. 아래 패턴은 스캐너가 발견하지 못해 늦게 요청된다.

피할 수 없을 때는 preload로 발견을 앞당긴다(리소스 힌트와 미리 불러오기). LCP 이미지가 이 패턴에 걸리면 LCP가 크게 늦어진다(LCP 최적화).

defer·async로 미루면 스크립트가 실행되기 전에 화면이 먼저 보인다. 그 스크립트가 붙이는 기능(버튼 동작, 위젯)은 준비될 때까지 로딩 표시를 두거나 disabled로 두어, 눌러도 반응 없는 상태를 숨기지 않는다. DOMContentLoaded·load가 각 스크립트를 기다리는지는 페이지 생명주기와 리소스 로딩 이벤트에 정리했다.

CSS는 head에, 스크립트는 defer로

과거에는 「CSS는 위, JS는 </body> 직전」이 정석이었다. defer가 모든 브라우저에서 일관되게 동작하는 지금은 <head> + defer(또는 type="module")가 기본이다. 스크립트를 본문 끝에 두면 HTML을 거의 다 받아 파싱한 뒤에야 발견되므로 내려받기가 그만큼 늦게 시작된다.

예외

내려받기 순서를 더 당기거나 미루는 힌트(preload, fetchpriority, loading)는 HTML 기초와 HTML5과 리소스 힌트와 미리 불러오기에 있다.

CSS를 가볍게

CSS가 렌더링을 막는 것은 FOUC를 막기 위해서라 나쁜 일이 아니다. 줄여야 할 것은 막는 시간이다.

JS도 같은 원리로 최소화하고, 번들러는 배포 빌드에서 식별자 이름까지 줄인다(uglify, 예: Terser). 기본 설정이 크기와 정확성의 균형을 대개 잘 맞춘다.

점진적 렌더링

점진적 렌더링(progressive rendering)은 페이지 전체가 준비될 때까지 기다리지 않고 받은 부분부터 먼저 화면에 보여 주는 기법을 통틀어 부르는 말이다. 총 로딩 시간이 같아도 사용자가 느끼는 속도가 빨라지고, FCP·LCP 같은 웹 성능 지표가 좋아진다. 느리고 불안정한 모바일 네트워크에서 특히 효과가 크다.

점진적 렌더링은 「먼저 보여 줄 것」과 「나중에 해도 되는 것」을 나누는 일이다. CSS를 <head>에 두는 것도 받는 대로 그릴 수 있게 하려는 같은 원칙에서 나온다.

역사

지금의 「<head>에 두고 defer」 원칙은 브라우저가 스크립트를 다루는 방식이 바뀌며 자리 잡았다.

다운로드와 실행 시점을 따로 제어하려던 당시의 꼼수(<object>나 가짜 type으로 받아 두기)는 지금 preload·modulepreload가 맡는다(리소스 힌트).

정리

• 일반 <script>는 파싱을 멈춘다. 외부 스크립트에는 defer, 독립 스크립트에는 async, 모듈은 그 자체로 defer다.
• defer는 문서 순서를 지키고 DOMContentLoaded 전에 끝난다. async는 순서를 보장하지 않는다.
• CSS는 <head>에서 일찍 받고, 스크립트도 <head>에 두되 defer로 미룬다.
• 첫 페인트 전에 꼭 필요한 아주 작은 코드만 동기 인라인으로 남긴다.

파서를 막지 말고, 첫 화면에 필요한 것부터 보낸다.

관련 노트: 브라우저 렌더링 과정, HTML 기초와 HTML5, 웹 성능 지표와 Lighthouse, 리소스 힌트와 미리 불러오기, LCP 최적화, 지연 로딩, 스트리밍 SSR, 모듈: export와 import, 문서 head와 메타데이터, 페이지 생명주기와 리소스 로딩 이벤트