웹 성능 지표

웹 사이트와 성능

사용자가 웹 사이트에 접속한다면

1. 방문한 목적을 손쉽게 달성할 수 있어야 하며,
2. 목적을 달성하는 데 걸리는 시간이 짧아야 하며,
3. 개인정보 누출과 같은 사고 없이 보안이 철저해야 한다.

크게 이 세가지가 달성된다면 웹사이트가 내부적으로 어떤 코드로 어떻게 이루어져 있는지는 고객들에게 전혀 중요하지 않다. 모든 서비스가 그렇듯 웹서비스도 마찬가지로 사용자가 느끼는 성능이 가장 중요하다.

그렇다면 이러한 웹사이트의 성능은 어떻게 측정할 수 있을까 ?

구글은 핵심 웹 지표(Core Web Vital)라고 하는, 웹사이트의 우수한 사용자 경험을 제공하는 필요한 몇가지 핵심적인 요소를 꼽고, 이에 대한 지표를 제시하고 있다.

핵심 웹 지표란?

핵심 웹 지표(Core Web Vital)란 구글에서 만든 지표로, 웹사이트에서 뛰어난 사용자 경험을 제공하는 데 필수적인 지표를 일컫는 용어이다. 구글에서는 사이트에서 핵심적인 웹 지표를 몇 가지로 요약하고, 이를 측정할 수 있는 방법, 그리고 좋은 웹사이트로 분류할 수 있는 기준을 제시한다.

구글에서 핵심 웹 지표로 꼽는 지표는 다음과 같다.

• 최대 콘텐츠풀 페인트(LCP: Largest Contentful Paint)
• 최소 입력 지연(FID: First Input Delay)
• 누적 레이아웃 이동(CLS: Cumulative Layout Shift)

다음 두 지표는 핵심까지는 아니지만, 특정 문제를 진단하는 데 사용할 수 있다고 언급했다.

• 최조 바이트까지의 시간(TTFB: Time To First Byte)
• 최초 콘텐츠풀 시간(FCP: First Contentful Paint)

최대 콘텐츠풀 페인트(LCP)

최대 콘텐츠풀 페인트(LCP: Largest Contentful Paint)는 페이지가 처음으로 로드를 시작한 시점부터 뷰포트 내부에서 가장 큰 이미지 또는 텍스트를 렌더링하는 데 걸리는 시간을 의미한다.

뷰포트는 사용자에게 현재 노출되는 화면을 의미하며 뷰포트 내부에서 ‘큰 이미지와 텍스트’는 다음과 같이 정의되어 있다.

• <img>
• <svg> 내부의 <image>
• poster 속성을 사용하는 <video>
• url()을 통해 불러온 배경 이미지가 있는 요소
• 텍스트와 같이 인라인 요소를 포함하고 있는 블록 레벨 요소
  • 블록 레벨 요소에는 <p>, <div> 등이 포함된다.

실제 크기가 크다고 하더라도 뷰포트 영역 밖에 넘치는 요소가 있다면 해당 영역의 크기는 고려되지 않는다. LCP에 영향을 미치는 부분은 오직 뷰포트 영역뿐이다.

LCP는 페이지 로딩에 따라 변화하는 지표이다. 사용자가 이용하는 디바이스 크기에 따라, 그리고 그것이 이미지와 같이 비교적 크기가 큰 리소스라면 실제로 로딩에 필요한 시간에 따라 LCP 지표의 값이 달라질 수 있다. 예를 들어, 헤더가 가장 먼저 노출된다면 LCP는 헤더이다. 그 다음 콘텐츠가 로딩되며 이미지가 노출된다면 LCP는 이미지로 변경된다.

LCP에서 좋은 점수란 해당 지표가 2.5초 내로 응답이 오는 것이다. 4초 이내로 응답이 온다면 보통, 그 이상이 걸리면 나쁨으로 판단된다.

이 점수를 높이는 방법은 무엇일까 ?

텍스트 사용

LCP 지표에서 좋은 점수를 얻는 가장 확실한 방법은 뷰포트 최대 영역, 즉 LCP 예상 영역에 이미지가 아닌 문자열을 넣는 것이다. 아무리 이미지를 최적화 하더라도 리소스 다운로드가 필요한 이미지보다 텍스트 노출이 훨씬 더 빠를 것이다.

이미지를 불러오는 방법

하지만 사용자에게 좀 더 강한 인상을 주기 위해서는 이미지를 사용하기 원할 것이다. 이미지를 노출할 수 있는 방법에는 여러가지가 있다.

// 1. img
<img src="lcp.jpg" />
// 2. svg
<svg xmlns="http://www.w3.org/1000/svg">
	<image href="lcp.jpg" />
</svg>
// 3. video poster
<video poster="lcp.jpg"></video>
// 4. background-image: url()
<div style="background-image: url(lcp.jpg)"></div>

각 방법을 사용했을 때 이미지 로딩 속도에 어떠한 차이가 있는지 살펴보자

• <img>: 이미지는 브라우저의 프리로드 스캐너에 의해 먼저 발견되어 빠르게 요청이 일어난다. 프리로드 스캐너란 HTML을 파싱하는 단계를 차단하지 않고 이미지와 같이 빠르게 미리 로딩하면 좋은 리소스를 먼저 찾아 로딩하는 브라우저 기능이다. <img>는 HTML 파싱이 완료되지 않더라도 프리로드 스캐너가 병렬적으로 리소스를 다운로드하므로 LCP를 불러오기에 적절한 방법이다.
• <svg> 내부의 <img>: <svg> 내부의 <img>가 로딩이 완료되기 전까지는 LCP가 완료되지 않는다. 또한 <img>와 달리 모든 리소스를 다 불러온 이후에 이미지를 불러온다.
• <video>의 poster: poster는 사용자가 비디오 요소를 재생하거나 탐색하기 전까지 노출되는 요소이다. 이는 프리로드 스캐너에 의해 발견되어 <img>와 같은 성능을 나타낸다. 만약 poster가 없는 비디오의 경우 비디오를 실제로 로딩해 첫번째 프레임을 해당 poster 리소스로 대체한다. 그러므로 비디오가 LCP에 영향을 받을 것 같다면 poster를 넣어주는 것이 좋다.
• background-img: url(): CSS에 있는 리소스는 항상 느리다. 이러한 리소스는 브라우저가 해당 리소스를 필요로 하는 DOM을 그릴 준비가 될 때까지 리소스 요청을 뒤로 미루기 때문이다. 즉, LCP에도 좋은 영향을 미치지 않는다. 가능하다면 background-image는 LCP와 같이 중요한 리소스에는 사용하지 않는 것이 좋다.

그 밖에 조심해야 할 사항

• loading=lazy 주의: loading=lazy는 리소스를 중요하지 않음으로 표시하고 필요할 때만 로드하는 전략이다. 문제는 LCP의 이미지는 중요하지 않은 이소스로 분류해서는 안된다는 것이다. 상대적으로 중요하지 않은 이미지에서만 사용해야 한다.
• 애니메이션: 이미지가 그냥 뜨는 것보다 애니메이션과 함께 처리된다면 LCP도 그만큼 늦어진다.
• 클라이언트에서 빌드하지 말 것: 가장 최적의 시나리오는 서버에서 빌드해온 HTML을 프리로드 스캐너가 바로 읽어 LCP로 빠르게 가져가는 것이다. 하지만 useEffect같은 클라이언트 코드가 있다면 LCP는 HTML을 다운로드한 직후가 아닌 리액트 코드를 파싱하고 읽어서 요청을 보내고 받는 만큼 늦어지게 된다. 따라서 가능한 서버에서 미리 빌드된 채로 오는 것이 좋다.
• 최대 콘텐츠풀 리소스는 직접 호스팅: 가능하다면 직접 호스팅하는 것이 좋다. 다른 출처에서 이미지를 가져오는 경우 네트워크 커넥션부터 다시 수행해야 하기 때문이다.

최초 입력 지연(FID)

아무리 페이지가 빨리 로딩된다 하더라도 사용자가 클릭을 비롯한 웹사이트와 상호작용을 할 수 없다면 사용자는 웹사이트가 느리다고 생각할 것이다. 이처럼 웹사이트의 로딩 속도만큼 중요한 것이 웹사이트의 반응 속도이다. 이러한 웹사이트의 반응성을 측정하는 지표가 최초 입력 지연(FID: First Input Delay)이다. FID는 사용자가 페이지와 처음 상호 작용할 때(링크나 버튼을 클릭하는 등)부터 해당 상호 작용에 대한 응답으로 브라우저가 실제로 이벤트 핸들러 처리를 시작하기까지의 시간을 측정한 것이다. 모든 입력에 대해 측정하는 것이 아니며, 최초의 입력 하나에 대해서만 그 응답 지연이 얼마나 걸리는지 판단한다.

대부분의 이벤트 핸들러에는 이벤트를 즉시 처리하기 위한 코드를 작성하는 것이 일반적이다. 그렇다면 웹사이트 내부의 이벤트가 반응이 늦어지는 이유는 무엇일까 ? 그 이유는 해당 입력을 처리해야 하는 브라우저의 메인 스레드가 바쁘기 때문이다. 메인스레드가 바쁜 경우, 자바스크립트 실행 환경은 싱글 스레드이기 때문에 자바스크립트가 이벤트 리스너와 같은 다른 작업을 실행할 수 없어 지연이 발생한다. 즉, 이벤트가 발생하는 시점에 최대한 메인 스레드가 다른 작업을 처리할 수 있도록 여유를 만들어야 사용자에게 빠른 반응성을 보장할 수 있다.

FID의 좋은 점수를 얻기 위해서는 100ms 이내로 응답이 와야 하며, 300ms 이내인 경우 보통, 그 이후의 경우에는 나쁨으로 처리된다.

FID를 개선하려면 메인 스레드에 이벤트를 실행할 여유를 주어야 한다.

실행에 오래 걸리는 긴 작업을 분리

긴 작업이란 실행을 완료하는 데 오래 걸리는 작업을 의미한다. 메인 스레드를 오래 점유해야 하는 긴 작업은 FID뿐만 아니라 웹페이지 전반에 악영향을 미친다. 이 경우 몇가지 대안을 연구해야 한다.

우선, 꼭 웹페이지에서 해야 하는 작업인가를 고민해야 한다. 만약 아니라면 서버로 옮겨서 처리하는 것이 좋다.

만약 꼭 웹페이지에서 처리해야 하는 작업이라면 해당 작업을 여러개로 분리하는 것이 좋다. 일반적으로 크롬의 경우 50ms 이상 걸리면 오래 걸리는 작업이라고 간주한다. 작업을 분리한다는 것은 단순히 실행이 오래걸릴 것 같은 작업을 분리하는 것 뿐만 아니라 웹페이지 최초 로딩에 필요하지 않은 내용을 나중에 불러오는 것도 포함된다. 예를들어, 사용자의 액션으로 인해 노출되는 요소들은 당장의 로딩에 필요하지 않으므로 리소슨는 리액트의 Suspense와 lazy를, 훅은 Next.js의 dynamic을 이용해 나중에 불러오게 할 수 있다.

자바스크립트 코드 최소화

번들러가 빌드 과정에서 사용되지 않은 코드를 번들링에서 제거하더라도 여전히 경우에 따라 웹페이지를 불러오는 데 사용되지 않는 필요 없는 코드가 존재할 수 있다. 이러한 코드를 크롬 개발자 도구를 통해 확인할 수 있다.

사이트 방문 후, 크롬 개발자도구의 커버리지를 클릭한다(command + shift + p → show command 검색). 기록 버튼을 클릭하면 커버리지가 기록된다. 아래는 나의 블로그의 커버리지를 기록한 것이다.

현재까지 웹페이지에서 사용되지 않은 코드가 얼마나 있는지 확인할 수 있다. 여기에 표시된 모든 코드들이 필요 없는 코드이므로 삭제해야 한다는 것은 아니다. 사용자의 특정 이벤트에 따라 실행되는 코드나, 예기치 못한 상황에서 실행될 코드 등 다양한 것들이 존재할 수 있다. 이러한 코드들은 당장 급한 코드가 아니므로 지연 로딩 기법이나 사용자가 필요로 하는 순간에 불러오거나 우선순위를 낮추어 불러오는 것이 좋다.

타사 자바스크립트 코드 실행의 지연

Google Analytics나 Firebase와 같이 웹페이지의 통계 집계를 통해 타사 스크립트를 넣는 경우가 있다. 이러한 코드의 실행으로 인해 메인 스레드가 점유되고 이로 인해 사용자에게 안 좋은 반응성을 제공하는 경우가 생길 수 있다.

타사 스크립트는 대부분 웹페이지 로드에 중요한 자원이 아니므로 <script>의 async와 defer를 이용해 지연 불러오기를 하는 것이 좋다.

• defer: script에 defer 속성이 있다면 먼저 해당 스크립트를 다른 리소스와 함께 병렬로 다운로드한다. 다운로드 중에도 HTML 파싱 등의 메인 스레드 작업은 멈추지 않으며, 다운로드가 완료된 이후에도 이 스크립트의 실행은 페이지가 완전히 로딩된 이후에 마지막에 실행된다.
• async: script에 async 속성이 있다면 해당 스크립트를 다른 리소스의 함께 병렬로 다운로드한다. 다운로드가 완료된 이후에는 다른 리소스의 다운로드 완료를 기다리지 않고 바로 실행한다.

타사 자바스크립트는 가능하면 async를, 더 가능하다면 defer로 지연하는 것이 좋다.

만약 광고와 같이 실제 사용자의 뷰포트 위치에 따라 불러와야 하는 컴포넌트는 Intersection Observer를 이용해 뷰포트에 들어오는 시점에 불러오는 것이 좋다. 사용자가 기대하지 않은 추가적인 리소스는 실행을 조금 뒤로 미뤄두고 실행하는 시점을 최적화하는 것이 좋다.

누적 레이아웃 이동(CLS)

웹사이트에서 무언가를 클릭하려 했는데 그 사이 다른 요소가 로딩되면서 원래 클릭하려 했던 요소를 클릭하지 못해 당황했던 적이 있을 것이다. 이처럼 페이지의 생명주기동안 발생하는 예기치 않은 이동에 대한 지표를 계산하는 것이 누적 레이아웃 이동(CLS: Cumulative Layout Shift)이다. 다른 지표와 마찬가지로 이 지표가 낮을수록, 즉 사용자가 겪는 에상치 못한 레이아웃 이동이 적을수록 더 좋은 웹사이트이다.

다음 예제를 살펴보자

function Banner() {
  const [show, setShow] = useState(false);
 
  useEffect(() => {
    (async function () {
      const result = await fetchBannerInfo();
      if (result.ok) {
        setShow(true);
      }
    })();
  }, []);
 
  if (!show) {
    return null;
  }
 
  return <BannerHeader>이벤트 진행 중 !</BannerHeader>;
}

이 예제는 useEffect 내부에서 배너 관련 정보를 요청한 다음 응답이 오면 배너를 띄우는 컴포넌트이다. 렌더링이 완료된 이후 API의 응답을 받아 다시 배너가 노출되면 레이아웃이 변경된다. 이처럼 최초 렌더링 이후 실행되는 useEffect가 많을수록, 그리고 이 useEffect가 렌더링에 영향을 미칠수록 CLS에 좋지 못한 점수를 받을 가능성이 크다.

CLS는 뷰포트 내부의 요소에 대해서만 측정한다. 요소가 추가됐다 하더라도 다른 요소의 시작 위치에 영향을 미치지 않았다면 레이아웃 이동으로 간주하지 않는다. 또한 사용자 액션으로 인해 발생한 레이아웃 이동은 점수에 포함되지 않는다.

CLS의 경우 0.1 이하인 경우 좋음, 0.25 이하인 경우 보통이며 그 외에는 개선이 필요한 나쁜 점수로 보고된다.

CLS를 개선할수 있는 방안들에 대해 살펴보자.

삽입이 예상되는 요소를 위한 추가적인 공간 확보

대부분의 CLS는 클라이언트에서 삽입되는 동적인 요소로 인해 발생한다. 이 외에도 갑자기 요소의 크기가 바뀌거나, 광고와 같은 타사 라이브러리가 브라우저에서 로드되는 등의 작업 때문에 나타난다.

이러한 영향을 방지하기 위해 useEffect 내부에서 요소에 영향을 미치는 작업, 특히 뷰포트 내부에서 노출될 확률이 높은 작업을 최소화하는 것이 좋다. useEffect 사용이 불가피하다면 useLayoutEffect 훅을 사용해 보는 것도 검토해볼만 하다. 그러나 useLayoutEffect는 동기적으로 발생해 브라우저의 페인팅 작업에 영향을 미치기 때문에 사용자에게 로딩이 오래 걸리는 것과 같이 보일 수 있으므로 신중하게 선택해야 한다.

스켈레톤 UI처럼 미리 무언가가 동적으로 뜰 것으로 예상되는 공간을 미리 확보해 두는 것도 좋은 방법이다. 레이아웃 이동을 막으면서 클라이언트 시점에 정해지는 콘텐츠를 안정적으로 보여줄 수 있다.

가장 좋은 방법은 서버 사이드 렌더링이다. 서버에서 이러한 동적인 요소의 유무를 판단하여 클라이언트에 HTML을 미리 제공한다면 클라이언트에서는 이러한 고민 없이 깔끔하게 처리할 수 있다.

폰트 로딩 최적화

폰트 또한 레이아웃 이동을 일으키는 원인 중 하나이다. 폰트로 인해 발생할 수 있는 문제는 크게 두가지이다.

• FOUT(flash of unstyled text): HTML 문서에서 지정한 폰트가 보이지 않고 대체 기본 폰트로 보이고 있다가 뒤늦게 폰트가 적용되는 현상
• FOIT(flash of invisible text): HTML 문서에서 지정한 폰트가 보이지 않고, 기본 폰트도 없어 텍스트가 없는 채로 있다가 뒤늦게 폰트가 로딩되며 페이지에 렌더링되는 현상

폰트는 각각 고유의 높이와 너비를 가지고 있기 때문에 지정한 폰트가 다운로드도기 전에 텍스트를 노출하려고 한다면 높이와 크기가 다른 기본 폰트를 기반으로 한 텍스트를 노출해 CLS가 발생할 수 있다. 지정 폰트로 웹페이지를 보여주고 싶다면 다음을 유념해야 한다.

• <link>의 preload 사용: <link> 요소의 rel=preload는 페이지에서 즉시 필요로 하는 리소스를 명시하는 기능이다. preload로 지정된 요소는 초기에 불러와야 하는 중요 리소스로 간주되므로 브라우저는 리소스를 더 빠르게 사용할 수 있도록 준비한다. 따라서 preload를 사용해 폰트를 지정하면 페이지의 렌더링을 가로막거나 레이아웃을 방해할 가능성이 줄어든다.
• font-family: 폰트를 불러올 수 있는 방법은 크게 다섯가지이다.
  • auto(기본): 브라우저가 폰트를 불러오는 방법을 결정한다.
  • block: 폰트가 로딩되기 전까지 렌더링을 중단한다. 웹 폰트 로딩이 완료되면 폰트를 적용한다.
  • swap: FOUT 방식으로, 우선 폴백 폰트로 글자를 렌더링 한 후 웹 폰트 로딩이 완료되면 적용한다.
  • fallback: 100ms간 텍스트가 보이지 않고 그 이후 폴백 폰트로 렌더링한다. 그리고 3초 내로 폰트가 로딩된다면 해당 폰트로 전환하고, 그렇지 않다면 폴백 폰트를 사용한다.
  • optional: 100ms간 텍스트가 보이지 않고 이후 폴백 폰트로 렌더링 한다. 그러나 0.1초 이내로 폰트가 다운로드돼 있거나 캐시돼 있지 않다면 폴백 폰트를 사용한다. 또한 브라우저가 네트워크 상태를 파악해 일정 기간 폰트를 다운로드하지 못한다면 연결을 취소한다.

CLS를 최소화 하려면 두 방법을 조합해 불러오는 것이 좋다. 최대한 중요한 폰트의 다운로드를 우선순위에 넣고, 이를 활용했음에도 빠르게 로딩하는데 실패했다면 기본 폰트를 노출하는 것이다.

적절한 이미지 크기 설정

반응형 웹사이트란 사용자 기기의 크기에 따라 자연스럽게 콘텐츠를 노출할 수 있도록 다양한 요소를 콘텐츠의 기기에 의존하도록 만든 웹사이트를 일컫는다.

img {
	width: 100%;
	height: auto;
}

위 예제는 너비는 기기의 너비대로, 높이는 그 그림이 너비를 가지면 자동으로 비례해 설정해 달라는 것을 의미한다.

그러나 이 경우 CLS가 커지는 결과를 낳는다. 높이를 이미지가 완전히 다운로드되기 전까지는 알 수 없기 때문에 이미지의 높이를 높게 잡아 뒀다가 이미지가 완전히 로딩된 이후에 기기의 너비만큼 높이를 계산해서 이미지의 크기만큼 자리잡게 된다. height: auto 는 반응형 웹사이트에 최적화할 수 있는 기법으로, 기기의 너비가 어떻게 되든 원본 가로세로 비율이 일정해 사용자에게 최적의 이미지를 보여줄 수 있다는 장점이 있다. 하지만 이미지의 높이를 명확히 알지 못하기때문에 레이아웃 이동이 발생한다는 단점이 있다. 이 문제를 해결하려면,

• width, height 지정: width와 height를 지정하는 것이 가장 좋다. width: 100%; height: auto; 와 함께 width, height를 원하는 비율로 지정하면 브라우저가 이미지 로딩 전 적절한 가로세로 비유을 계산해 이미지가 표시되는 만큼 면적을 할당해 둔다. aspect-ratio 속성 덕분인데, 이미지의 가로세로 비율을 자동으로 맞춰주는 역할을 한다.

  <img src="/imgae.jpg" alt="이미지" width="1600" height="900" />

• 사용자의 뷰포트 너비에 맞춰 다른 이미지를 제공하고 싶은 경우 srcset 속성을 사용하는 것이 좋다. 가로세로 비율이 같고 크기가 다른 여러 이미지를 미리 준비한 다음 브라우저 상황에 맞게 이미지를 사용할 수 있도록 하는 것이다.

  <img
    width="1000"
    height="1000"
    src="image-1000.jpg"
    srcset="image-1000.jpg 1000w, image-2000.jpg 2000w, image-3000.jpg 3000w"
    alt="이미지"
  />

핵심 웹 지표는 아니지만 성능 확인에 중요한 지표

최초 바이트까지의 시간(TTFB)

최초 바이트까지의 시간(TTFB: Time to First Byte)은 브라우저가 웹페이지의 첫 번째 바이트를 수신하는 데 걸리는 시간을 의미한다. 요청이 완전히 완료되는 시간을 측정하는 것이 아닌 최초의 응답이 오는 바이트까지가 얼마나 걸리는지를 측정하는 지표이다. 이 지표는 600ms 이상 걸릴 경우 개선이 필요한 것으로 간주된다.

서버 사이드 렌더링을 하고 있는 어플리케이션의 경우 최초 페이지를 만들기 위해 서버에서 어느 정도 작업을 수행해야 한다. 서버에서 첫 HTML을 만들기 위해 해야 하는 작업이 많거나 느릴수록 TTFB 또한 길어지게 될 것이다. 이를 개선하기 위해서는 다음과 같은 상황을 고려해야 한다.

• 서버 사이드 렌더링을 수행하고 있다면
  • 로직을 최적화해 페이지를 빨리 준비시켜야 한다. 페이지를 만드는데 필요한 작업을 최소화하고, 페이지를 그리는데 중요한 내용만 서버 사이드 렌더링에서 준비하는 등의 최적화가 필요하다.
  • 서버 사이드 렌더링 시에 API 호출이 필요하다면 호출 횟수와 가져오는 정보 크기를 최소화 해 최대한 응답 속도를 빠르게 하고 크기를 가능한 한 줄여야 한다.
• 리액트 서버 사이드 렌더링이라면 스트리밍 API를 사용하는 것이 좋다. 스트리밍을 사용할 경우 완성된 영역부터 조각조각 받을 수 있어 최초 바이트까지의 시간을 단축할 수 있다.

최초 콘텐츠풀 페인트(FCP)

최초 콘텐츠풀 페인트(FCP: First Contentful Paint)란 페이지가 로드되기 시작한 시점부터 페이지 콘텐츠의 일부가 화면에 렌더링될 때까지의 시간을 측정한다. 일반적으로 FCP는 1.8초 이내에 이루어진다면 좋음, 3.0초 이내는 보통, 그 이후는 개선이 필요한 것으로 보고된다.

FCP를 개선하려면 다음을 고려해야 한다.

• TTFB 개선: 일단 뭐라도 다운로드가 시작되어야 렌더링을 할수 있다. 빠른 렌더링을 위해 TTFB를 단축해야 한다.
• 렌더링을 가로막는 리소스 최소화: 자바스크립트나 CSS 같은 리소스를 최소하하고, 렌더링을 방해하는 리소스를 비동기적으로 로드하도록 한다.
• Above the Fold에 대한 최적화: 웹페이지에서 최초에 스크롤을 굳이 하지 않아도 보이는 영역을 Above the Fold라고 한다. 이 영역은 최대한 빠르게 보여주기 위해 게으른 로딩이나 스크립트에 의존해 요소가 렌더링되는 것을 피해야 한다.
• 페이지 리다이렉트 최소화
• DOM 크기 최소화: DOM이 복잡하고 크다면 그만큼 렌더링되는 데 시간이 오래 걸린다. 구글의 기준에 따르면 전체 DOM 노드는 1500개 미만으로, 깊이는 32단계 정도까지만, 그리고 부모 노드는 자식노드를 60개정도만 가지고 있어야 한다. DOM이 필요 이상으로 많고 복잡하다면 이를 줄이기 위한 방법을 고민해야 한다.

참고자료

모던 리액트 Deep Dive 12장 모든 웹 개발자가 관심을 가져야 할 핵심 웹 지표 참조