사전 로드, 사전 연결, 사전 가져오기: 리소스 힌트로 사이트 성능 향상

최신 웹 브라우저는 가장 중요한 리소스의 우선 순위를 지정하고 먼저 가져오는 것부터 사용자가 다음에 방문할 페이지를 추측하는 것까지 웹 사이트의 전반적인 성능을 향상시키기 위해 모든 종류의 다양한 기술을 사용합니다.

그러나 사이트 성능에 대한 모든 결정을 내리기 위해 브라우저가 아무리 발전했다고 해서 의존해서는 안 됩니다.

웹 사이트 소유자는 가장 중요한 리소스와 사이트의 실제 사용자 여정이 무엇인지 알고 있습니다. 그리고 웹사이트의 전반적인 성능, 인지된 속도 및 사용자 경험을 개선하기 위해 해당 지식을 사용하여 브라우저에서 페이지를 더 빠르게 로드할 수 있습니다.

리소스 힌트가 나오는 곳입니다.

다음 줄에서 우리는 그것들을 살펴보고 가능한 가장 좋은 방법으로 그 장점을 활용하는 방법을 살펴볼 것입니다.

자세히 살펴보겠습니다.

브라우저 작동 방식(간단히 말하면)

리소스 힌트와 적용 가능한 위치를 더 잘 이해하기 위해 브라우저가 실제로 콘텐츠를 로드하는 방법을 간단히 살펴보겠습니다.

브라우저가 페이지를 로드하는 전체 프로세스를 세 단계로 나눌 수 있습니다.

• 연결 설정;
• 코드 다운로드, 구문 분석 및 렌더링
• 페이지를 대화형으로 만들기

첫 번째 단계에서 브라우저는 리소스를 다운로드하기 위해 서버와 연결을 설정해야 합니다. 여기에는 도메인 이름 조회 및 IP 주소 확인, 서버 연결 설정, 보안을 위한 연결 암호화가 포함됩니다.

모든 작업이 완료되면 브라우저는 정보를 다운로드 및 구문 분석하고 DOM(문서 개체 모델) 및 CSSOM(CSS 개체 모델)을 구성한 다음 콘텐츠를 렌더링할 수 있습니다.

마지막 부분은 페이지를 대화형으로 만드는 것입니다. 위에서 언급한 모든 프로세스는 메인 스레드에서 발생합니다. 따라서 브라우저의 기본 스레드가 페이지 구문 분석, 렌더링 및 페인팅을 완료한 후에는 지연된 JavaScript 파일을 처리하여 페이지를 스크롤, 터치 및 기타 상호 작용에 사용할 수 있도록 해야 합니다.

간단히 말해서 페이지가 로드될 때마다 백그라운드 프로세스입니다.

리소스 힌트를 통합하여 이러한 각 단계에 긍정적인 영향을 미칠 수 있는 방법을 살펴보겠습니다.

리소스 힌트: 프리페치, 프리커넥트, 프리로드

이름에서 알 수 있듯이 리소스 힌트는 브라우저가 특정 리소스 또는 웹 페이지를 처리하는 방법을 알려주는 힌트 또는 지침입니다. 다시 말해, 이 지침 세트를 통해 브라우저가 가져와서 렌더링해야 하는 출처 또는 리소스의 우선 순위를 지정할 수 있습니다.

모든 리소스 힌트는 HTML 문서의 헤드 에서 찾을 수 있는 링크 요소의 rel 속성을 사용합니다.

이러한 HTML 코드 조각을 웹사이트에 통합하면 브라우저가 페이지를 로드하는 일반적인 과정을 통해 파일을 찾는 것보다 더 빨리 선택한 파일을 로드할 수 있습니다.

이제 기본 사항이 끝났으므로 리소스 힌트, 이점 및 사용 시기에 대한 개요를 보고자 하는 부분으로 이동하겠습니다.

프리페치

link rel=prefetch 는 브라우저가 나중에 필요할 수 있는 리소스를 가져와 브라우저 캐시에 저장할 수 있도록 하는 낮은 우선 순위 리소스 힌트입니다.

프리페치 는 매우 낮은 우선순위를 설정 하므로 중요도가 높은 파일에는 이 힌트를 사용하지 마십시오 .

훌륭한 사용 사례 중 하나는 프리페치 를 활용하여 후속 페이지의 로드 시간을 개선하는 것입니다. 예를 들어 사용자 인증 중에 prefetch 지시문을 적용할 수 있습니다. 이렇게 하면 다음에 보게 될 페이지에 필요한 리소스를 미리 로드하기 위해 자격 증명을 입력하는 데 걸리는 시간을 활용할 수 있습니다.

사이트에서 방문자의 단계를 예상하고 리소스를 미리 가져오면 First Contentful Paint 및 Time to Interactive와 같은 측정항목을 개선할 수 있습니다. Netflix가 인터랙티브 시간을 30% 단축한 것입니다.

지금까지 언급한 모든 것은 링크 프리페칭이라고도 하는 프리페칭과 관련이 있습니다. 그러나 똑같이 중요한 두 가지 다른 유형의 프리페치가 있으며 다음을 언급해야 합니다.

1. DNS 프리페칭
브라우저는 호스트(원본 서버)에 연결하기 전에 호스트 이름(URL)을 IP 주소로 변환하기 위해 DNS 조회를 수행해야 합니다.

일반적으로 몇 밀리초 밖에 걸리지 않지만 웹 사이트가 타사 도메인 이름에서 파일을 로드하는 경우(대부분의 웹 사이트에서 수행하는 작업) 브라우저는 각 도메인에 대해 DNS 조회를 수행해야 합니다. 일부 사이트(예: 뉴스 웹사이트)는 많은 외부 리소스를 사용하므로 페이지당 수십 개의 DNS 조회가 필요할 수 있습니다.

이러한 경우 dns-prefetch 힌트를 사용하면 명령이 브라우저에서 로드 프로세스의 후반부에 필요가 발견되는 것이 아니라 해당 프로세스를 즉시 시작하도록 지시할 때 몇 밀리초를 절약할 수 있습니다.

Web Almanac 2021에서 제안한 것처럼 최적의 결과를 위해 dns-prefetch 를 사전 연결 힌트와 결합하는 것이 좋습니다. preconnect 에 대해 이야기하는 섹션에서 그 이유를 알 수 있습니다.

2. 사전 렌더링
사전 렌더링은 사용자가 다음에 탐색할 수 있는 리소스를 최적화한다는 점에서 사전 가져오기와 매우 유사합니다. 차이점은 사전 렌더링이 실제로 특정 리소스 대신 전체 페이지 를 렌더링한다는 것입니다.

사전 연결

dns-prefetch 와 마찬가지로 preconnect 지시문은 브라우저가 서버에 초기 요청을 보내기 전에 초기 연결을 설정하는 데 도움이 됩니다.

그러나 사전 연결 힌트는 한 단계 더 나아갑니다. DNS 조회를 수행하는 동안 TLS 협상 및 TCP 핸드셰이크도 포함됩니다. 이는 차례로 왕복 대기 시간을 제거하고 더 많은 시간을 절약합니다.

그러나 여기에 질문이옵니다.

사전 연결 이 dns-prefetch 가 수행하는 모든 작업을 수행하고 위의 경우 처음에 dns-prefetch 를 사용하는 이유는 무엇입니까?

대부분의 경우 사전 연결 이 dns-prefetch 보다 선호되는 옵션이지만 문제는 사전 연결 이 일부 브라우저에서 지원되지 않는다는 것입니다.

출처: caniuse.com

좋은 점은 함께 사용하여 최대한 활용할 수 있다는 것입니다. dns-prefetch 에 대한 폴백으로 이를 지원하는 브라우저에서 사전 연결 의 이점을 누릴 수 있습니다.

구글에 따르면:

2019년에 Chrome은 중요한 출처에 미리 연결하여 Time To Interactive를 거의 1초로 개선했습니다.

예압

preload 지시문이 어떻게 작동하는지 설명하기 전에 우리는 뭔가를 분명히 해야 합니다.

사전 로드 는 정기적으로 "리소스 힌트"로 언급되지만 그렇지 않습니다. 사전 로드는 선언적 가져오기이며 브라우저에 필수 이므로 힌트라기보다는 명령에 가깝습니다.

즉, 사전 로드 는 페이지에 중요하기 때문에 브라우저가 리소스를 검색하는 것보다 더 빨리 브라우저가 리소스를 다운로드하도록 하는 데 사용됩니다 .

preload 지시문은 중요한 렌더링 경로의 일부이지만 브라우저에서 쉽게 발견되지 않는 리소스에서 가장 잘 작동합니다. 예를 들어 글꼴, CSS 또는 중요한 JavaScript.

dns-prefetch 및 preconnect 힌트와의 또 다른 차이점은 rel 및 href 속성만 필요하지만 사전 로드 는 더 복잡하다는 것입니다. 미리 로드하려는 리소스의 콘텐츠 유형을 나타내는 as 속성을 추가해야 합니다.

Google의 엔지니어링 관리자인 Addy Osmani에 따르면 사전 로드 시 as 속성을 제공하는 것은 필수입니다.

지정할 수 있는 as 값의 전체 목록은 다음과 같습니다.

as 속성을 포함하면 브라우저가 해당 유형에 따라 프리페치된 리소스의 우선 순위를 설정하고 리소스가 이미 캐시에 있는지 여부를 결정하는 데 도움이 됩니다.

다양한 리소스 유형의 우선 순위를 지정하는 방법에 대해 자세히 알아보려면 Chrome 리소스 우선 순위 및 일정 문서를 확인하세요.

글꼴과 같은 일부 리소스의 경우 crossorigin 속성도 포함해야 합니다.

crossorigin 속성은 요청 모드를 HTTP CORS 요청으로 설정합니다. CORS(Cross-Origin Resource Sharing)는 브라우저가 리소스 로드를 허용해야 하는 원본 이외의 원본을 서버가 나타낼 수 있도록 하는 메커니즘입니다. 이 기사의 초점이 아니기 때문에 이에 대해 더 깊이 파고들지는 않겠지만 여기에서 더 많은 정보를 찾을 수 있습니다.

그리고 as 속성과 유사하게 crossorigin 없이 글꼴을 미리 로드하면 이중 가져오기가 수행됩니다. 다음은 해당 주제에 대한 Addy Osmani의 기사에서 발췌한 또 다른 내용입니다.

더 많은 리소스 힌트, 더 많은 문제

지금까지 모든 것을 읽으면서 가능한 한 많은 리소스 힌트를 사용하면 브라우저가 페이지를 번개처럼 빠르게 로드할 수 있다고 생각할 수 있습니다.

불행히도 이것은 사실이 아닙니다.

다음은 리소스 힌트를 통합할 때 고려해야 할 몇 가지 문제입니다.

1. 프리페치가 데이터 소비를 증가시킬 수 있음

프리페치 는 낮은 다운로드 우선 순위를 설정하지만 이것이 무해하다는 의미는 아닙니다. 이를 사용하면 사이트의 데이터 소비가 증가하여 귀하(서버의 트래픽 증가)와 사용자(불필요한 리소스 과소비) 모두에게 문제가 발생할 수 있습니다. 또한 결국에는 사용되지 않을 수 있는 추가 바이트를 로드하게 될 수 있습니다. 따라서 통합하기 전에 두 번 생각하십시오.

2. 사전 렌더링은 대역폭 낭비를 유발할 수 있습니다.

전체 페이지를 미리 다운로드하기 때문에 prerender 를 사용한 도박은 prefetch 보다 훨씬 큽니다. 이로 인해 힌트 리소스가 많이 사용되며 특히 모바일 장치에서 대역폭 낭비가 발생할 수 있습니다. 그리고 최악의 부분은 사용자가 페이지를 요청하지 않으면 힌트의 효과조차 보지 못할 수 있다는 것입니다.

3. 사전 연결로 인해 CPU 사용량이 늘어날 수 있습니다.

사전 연결 은 우선 순위가 낮은 힌트이지만 여전히 웹 사이트 성능에 해를 끼칠 수 있습니다. 설정된 연결이 빠르게 사용되지 않으면(Chrome에서 10초 이내) preconnect 지시문은 CPU 사용량을 추가하기만 하고 브라우저에서 자동으로 닫힙니다. 또한 암호화 인증서의 크기가 약 3KB이므로 다른 중요한 리소스에 대한 대역폭과 경쟁하게 되므로 사전 연결 을 아껴 사용해야 합니다.

4. 사전 로드는 브라우저의 분석기가 설정한 우선 순위를 무시합니다.

preload 는 브라우저가 리소스를 즉시 다운로드하도록 하기 때문에 강력한 명령입니다. 그러나 최신 웹 브라우저는 리소스의 우선 순위를 지정하는 데 매우 능숙하므로 사전 로드 를 과도하게 사용하면 부정적인 결과가 발생할 수 있습니다. 예를 들어, 비동기 리소스 URL과 일치하는 사전 로드 지시문을 추가하면 브라우저가 이를 더 빠르게 가져오므로 더 빠르게 구문 분석하여 페이지 로드 초기에 메인 스레드를 중단하여 비동기 속성의 효과를 무효화합니다.

요약

이 기사에서 많은 내용을 다루었으므로 가장 중요한 요점을 간단히 요약해 보겠습니다.

• dns-prefetch 및 preconnect 는 도메인 이름의 우선 순위를 지정하는 데 사용됩니다(예: https://example.com).
• prefetch 및 preload 는 리소스 로드의 우선 순위를 지정하는 데 사용됩니다. 프리페치 는 후속 페이지의 로드 시간을 개선하는 데 사용되지만 프리로드는 현재 페이지의 중요한 리소스에서 가장 잘 작동합니다.
• 사전 렌더링 은 전체 페이지(예: blog.html)를 참조합니다.
• prefetch , prerender 및 preconnect 는 리소스 힌트이며 브라우저가 적합하다고 생각하는 대로 실행됩니다. preload 지시문은 브라우저에 필수 명령입니다.
• preload 를 사용할 때 이중 가져오기를 방지하기 위해 as 및 crossorigin 속성을 제공하는 것을 잊지 마십시오.
• 리소스 힌트는 우선 순위가 낮은 지침이지만 여전히 사이트 성능에 위협이 됩니다. 적당히 그리고 필요할 때만 사용하십시오.
• preload 는 브라우저 분석기의 우선 순위를 무시할 수 있는 강력한 지시문입니다. 최신 브라우저는 리소스의 우선 순위를 지정하는 데 매우 능숙하므로 사전 로드 "힌트"를 아껴서 사용하십시오.

리소스 힌트에 대해 새로 습득한 지식을 사용하여 콘텐츠 및 자산 전달 속도를 높이고 사이트의 전반적인 성능을 향상시키십시오. 변경할 때마다 실제 환경에서 웹사이트를 테스트하는 것을 잊지 마십시오(현장 데이터에 집중).