리소스 힌트로 성능 최적화

게시 됨: 2022-03-10

빠른 요약 ↬ 사용자가 실제로 수행하기 전에 수행할 작업을 예측할 수 있을 때 많은 성능 최적화를 수행할 수 있습니다. 리소스 힌트는 웹 개발자가 브라우저가 사용자보다 한 발 앞서 있고 페이지를 빠르게 유지하도록 도울 수 있는 간단하지만 효과적인 방법입니다.

최신 웹 브라우저는 모든 종류의 기술을 사용하여 사용자가 다음에 할 수 있는 작업을 추측하여 페이지 로드 성능을 향상시킵니다. 브라우저는 우리 사이트나 애플리케이션 전체에 대해 잘 알지 못하며, 종종 사용자가 할 수 있는 일에 대한 가장 좋은 통찰력은 개발자인 우리에게서 나옵니다.

사진 앨범과 같이 페이지가 매겨진 콘텐츠의 예를 살펴보겠습니다. 사용자가 앨범의 사진을 보고 있는 경우 '다음' 링크를 클릭하여 앨범의 다음 이미지를 볼 가능성이 상당히 높다는 것을 알고 있습니다. 그러나 브라우저는 페이지의 모든 링크 중 사용자가 클릭할 가능성이 가장 높은 링크를 실제로 알지 못합니다. 브라우저에서 이러한 모든 링크는 동일한 가중치를 갖습니다.

브라우저가 사용자가 다음에 어디로 가는지 알 수 있고 사용자가 링크를 클릭할 때 페이지 로드가 훨씬 더 빨라지도록 미리 다음 페이지를 가져올 수 있다면 어떨까요? 이것이 원칙적으로 리소스 힌트가 무엇인지입니다. 개발자가 미래에 일어날 가능성에 대해 브라우저에 알려주는 방법 이므로 브라우저가 리소스를 로드하는 방법에 대한 선택 사항을 고려할 수 있습니다.

이러한 모든 리소스 힌트는 HTML 문서의 <head> 에서 찾을 수 있는 <link> 요소의 rel 속성을 사용합니다. 이 기사에서는 리소스 힌트의 주요 유형과 페이지에서 언제 어디서 사용할 수 있는지 살펴보겠습니다. 우리는 작고 미묘한 힌트에서 마지막에 큰 총까지 갈 것입니다.

점프 후 더! 아래에서 계속 읽기 ↓

DNS 프리페칭

DNS 조회는 example.com 과 같은 인간 친화적인 도메인 이름을 리소스를 가져오기 위해 실제로 필요한 123.54.92.4 와 같은 기계 친화적인 IP 주소로 바꾸는 프로세스입니다.

브라우저 주소 표시줄에 URL을 입력하거나 페이지의 링크를 따라가거나 다른 도메인의 이미지와 같은 리소스를 로드할 때마다 브라우저는 DNS 조회를 수행하여 우리가 보유한 리소스를 보유하고 있는 서버를 찾아야 합니다. 요청했습니다. 외부 리소스가 많은 바쁜 페이지(예: 광고와 트래커가 많은 뉴스 웹사이트)의 경우 페이지당 수십 개의 DNS 조회가 필요할 수 있습니다.

브라우저는 이러한 조회 결과를 캐시하지만 속도가 느릴 수 있습니다. 한 가지 성능 최적화 기술은 리소스를 더 적은 수의 도메인으로 구성하여 필요한 DNS 조회 수를 줄이는 것입니다. 이것이 불가능할 때 dns-prefetch 리소스 힌트를 사용하여 검색해야 하는 도메인에 대해 브라우저에 경고할 수 있습니다.

 <link rel="dns-prefetch" href="https://images.example.com">

브라우저가 이 힌트를 발견하면 아직 사용 방법을 알지 못하더라도 최대한 빨리 images.example.com 도메인 이름 확인을 시작할 수 있습니다. 이를 통해 브라우저는 게임보다 앞서나가고 동시에 더 많은 작업을 수행하여 전체 로드 시간을 줄일 수 있습니다.

언제 `dns-prefetch` 사용해야 합니까?

페이지가 다른 도메인의 리소스를 사용하는 경우 dns-prefetch 를 사용하여 브라우저를 먼저 시작할 수 있습니다. 브라우저 지원은 정말 훌륭하지만 브라우저가 지원하지 않으면 아무런 해가 없습니다. 프리페치가 발생하지 않습니다.

사용하지 않는 도메인을 미리 가져오지 마십시오. 많은 수의 도메인을 미리 가져오려는 경우 해당 도메인이 모두 필요한 이유와 그 수를 줄이기 위해 할 수 있는 조치가 있는지 확인하는 것이 좋습니다.

사전 연결

DNS 프리 페칭 의 한 단계는 서버에 미리 연결하는 것입니다. 리소스를 호스팅하는 서버에 대한 연결을 설정하려면 여러 단계를 거쳐야 합니다.

DNS 조회 (방금 논의한 대로);
TCP 핸드셰이크
연결을 만들기 위한 브라우저와 서버 간의 간단한 "대화"입니다.
HTTPS 사이트의 TLS 협상
이는 인증서 정보가 연결에 대해 유효하고 올바른지 확인합니다.

이는 일반적으로 서버당 한 번 발생하며 귀중한 시간이 소요됩니다. 특히 서버가 브라우저에서 매우 멀리 떨어져 있고 네트워크 대기 시간이 긴 경우에 그렇습니다. (여기가 바로 전 세계적으로 분산된 CDN이 정말 도움이 되는 부분입니다!) DNS를 미리 가져오는 것이 브라우저가 어떤 일이 일어날지 알기 전에 게임에서 앞서 나가는 데 도움이 되는 것과 같은 방식으로, 서버에 미리 연결하면 브라우저가 어느 부분에 도달했는지 확인할 수 있습니다. 리소스가 필요한 페이지에서 연결을 설정하는 느린 작업이 이미 수행되었으며 회선이 열려 있고 사용할 준비가 되어 있습니다.

 <link rel="preconnect" href="https://scripts.example.com">

언제 `preconnect` 을 사용해야 합니까?

다시 말하지만, 브라우저 지원은 강력하며 브라우저가 사전 연결을 지원하지 않아도 해가 되지 않습니다. 결과는 이전과 동일합니다. 리소스에 액세스할 것이라는 확신이 있고 앞서 가고 싶은 경우 사전 연결을 사용하는 것이 좋습니다.

미리 연결한 다음 연결을 사용하지 않도록 주의하십시오. 이렇게 하면 페이지 속도가 느려지고 연결하는 서버의 리소스도 약간 소모됩니다.

다음 페이지 미리 가져오기

지금까지 살펴본 두 가지 힌트는 주로 로드되는 페이지 내의 리소스에 중점을 둡니다. 예를 들어, 브라우저가 이미지, 스크립트 또는 글꼴에서 앞서 나가는 데 도움이 될 수 있습니다. 다음 몇 가지 힌트는 탐색 및 사용자가 현재 로드 중인 페이지를 따라갈 위치 를 예측하는 것과 더 관련이 있습니다.

첫 번째는 프리페칭이며 링크 태그는 다음과 같을 수 있습니다.

 <link rel="prefetch" href="https://example.com/news/?page=2" as="document">

이렇게 하면 브라우저에 계속해서 백그라운드에서 페이지를 가져올 수 있음을 알려주므로 요청 시 이동할 준비가 됩니다. 사용자가 다음에 탐색할 것으로 생각되는 곳을 선점해야 하기 때문에 여기에 약간의 도박이 있습니다. 제대로 이해하면 다음 페이지가 정말 빨리 로드되는 것처럼 보일 수 있습니다. 잘못 이해하면 사용하지 않을 것을 다운로드하는 데 시간과 리소스를 낭비하게 됩니다. 사용자가 제한된 휴대전화 요금제와 같이 요금제 연결을 사용하는 경우 실제로 실제 비용을 지불해야 할 수 있습니다.

프리페치가 발생하면 브라우저는 DNS 조회를 수행하고 이전 두 가지 유형의 힌트에서 본 서버 연결을 수행하지만 한 단계 더 나아가 실제로 파일을 요청하고 다운로드합니다. 그러나 해당 지점에서 중지되고 파일이 구문 분석되거나 실행되지 않으며 현재 페이지에 적용되지 않습니다. 그들은 요청을 받았을 뿐이며 준비되어 있습니다.

프리페치는 브라우저의 캐시에 파일을 추가하는 것과 비슷하다고 생각할 수 있습니다. 사용자가 링크를 클릭할 때 서버로 이동하여 다운로드할 필요 없이 파일을 메모리에서 꺼내 훨씬 빠르게 사용할 수 있습니다.

속성 `as`

위의 예에서 as 속성을 as="document" 설정하고 있음을 알 수 있습니다. 이것은 우리가 가져오는 것이 문서(예: 웹 페이지)로 처리되어야 함을 브라우저에 알려주는 선택적 속성입니다. 이를 통해 브라우저는 마치 새 페이지에 대한 링크를 따라가는 것처럼 동일한 종류의 요청 헤더 및 보안 정책을 설정할 수 있습니다.

브라우저가 다양한 유형의 프리페치를 적절한 방식으로 처리할 수 있도록 함으로써 as 속성에 대해 가능한 값이 많이 있습니다.

`as` 값	리소스 유형
`audio`	사운드 및 음악 파일
`video`	동영상
`Track`	비디오 또는 오디오 WebVTT 트랙
`script`	자바스크립트 파일
`style`	CSS 스타일 시트
`font`	웹 글꼴
`image`	이미지
`fetch`	XHR 및 Fetch API 요청
`worker`	웹 작업자
`embed`	멀티미디어 `<embed>` 요청
`object`	멀티미디어 `<object>` 요청
`document`	웹 페이지

as 속성으로 자원 유형을 지정하는 데 사용할 수 있는 다양한 값.

언제 `prefetch` 를 사용해야 합니까?

다시 prefetch 는 훌륭한 브라우저 지원을 제공합니다. 탐색 속도를 높이는 것이 사용자 경험에 긍정적인 영향을 미친다고 생각되는 경우 사용자가 사이트를 추적할 것이라는 합리적인 정도의 확신이 있을 때 사용해야 합니다. 이것은 나중에 사용되지 않는 리소스를 가져옴으로써 리소스를 낭비할 위험과 비교해야 합니다.

다음 페이지 사전 렌더링

prefetch 를 사용하여 브라우저가 백그라운드에서 사용할 준비가 된 파일을 다운로드하는 방법을 보았지만 그 시점에서 파일로 더 이상 수행된 작업이 없다는 점에 주목했습니다. 사전 렌더링은 한 단계 더 나아가 파일을 실행하여 실제로 페이지를 표시하는 것을 제외하고 페이지를 표시하는 데 필요한 거의 모든 작업을 수행합니다.

여기에는 JavaScript 파일 및 이미지와 같은 하위 리소스에 대한 리소스를 구문 분석하고 해당 리소스도 미리 가져오는 작업이 포함될 수 있습니다.

 <link rel="prerender" href="https://example.com/news/?page=2">

이것은 브라우저의 뒤로 버튼을 누를 때 볼 수 있는 일종의 빠른 로드 성능과 함께 다음 페이지 로드가 즉각적으로 느껴지도록 만들 수 있습니다. 그러나 여기에서 도박은 훨씬 더 큽니다. 파일을 요청하고 다운로드하는 데 시간을 할애할 뿐만 아니라 JavaScript 등과 함께 파일을 실행하기 때문입니다. 이것은 사용자가 페이지를 요청하지 않는 경우에 이점을 볼 수 없는 메모리와 CPU(따라서 배터리)를 사용할 수 있습니다.

언제 `prerender` 을 사용해야 합니까?

prerender 에 대한 브라우저 지원은 현재 매우 제한적이며 실제로 Chrome 및 이전 IE(Edge 아님)만 옵션을 지원합니다. 특별히 Chrome을 대상으로 하지 않는 한 유용성이 제한될 수 있습니다. 사용자가 혜택을 볼 수 없지만 그렇지 않은 경우 문제를 일으키지 않기 때문에 다시 "해가 없고 파울이 없는" 경우입니다.

리소스 힌트 사용하기

<link> 태그를 사용하여 HTML 문서의 <head> 에서 리소스 힌트를 사용하는 방법을 이미 보았습니다. 이것이 가장 편리한 방법일 수 있지만 Link: HTTP 헤더를 사용하여 동일한 결과를 얻을 수도 있습니다.

예를 들어 HTTP 헤더로 미리 가져오려면 다음을 수행합니다.

 Link: <https://example.com/logo.png>; rel=prefetch; as=image;

또한 JavaScript를 사용하여 상호 작용 사용에 대한 응답으로 리소스 힌트를 동적으로 적용할 수도 있습니다. W3C 사양 문서의 예를 사용하려면:

 var hint = document.createElement("link"); hint.rel = "prefetch"; hint.as = "document"; hint.href = "/article/part3.html"; document.head.appendChild(hint);

이렇게 하면 사용자가 페이지와 상호 작용하는 방식을 기반으로 사용자가 다음에 탐색할 위치를 더 쉽게 예측할 수 있으므로 몇 가지 흥미로운 가능성이 열립니다.

주의 사항

우리는 DNS를 확인하는 가장 가벼운 터치부터 백그라운드로 이동할 준비가 된 전체 페이지를 렌더링하는 것에 이르기까지 리소스를 미리 로드하는 점점 더 공격적인 4가지 방법을 살펴보았습니다. 이러한 힌트는 단지 그것이라는 것을 기억하는 것이 중요합니다. 브라우저가 성능을 최적화할 수 있는 방법에 대한 힌트입니다. 지시문이 아닙니다. 브라우저는 우리의 제안을 받아들이고 응답 방법을 결정할 때 최선의 판단을 할 수 있습니다.

이는 사용량이 많거나 너무 많은 장치에서 브라우저가 힌트에 전혀 응답하지 않는다는 것을 의미할 수 있습니다. 예를 들어 브라우저가 측정된 연결에 있다는 것을 알고 있으면 전체 리소스가 아니라 DNS를 미리 가져올 수 있습니다. 메모리가 부족한 경우 브라우저는 현재 페이지가 오프로드될 때까지 다음 페이지를 가져올 가치가 없다고 다시 결정할 수 있습니다.

현실은 데스크탑 브라우저에서 힌트는 개발자가 제안한 대로 모두 따를 가능성이 높지만 모든 경우에 브라우저에 달려 있다는 점을 명심하십시오.

유지 관리의 중요성

몇 년 이상 웹 작업을 해 본 사람이라면 페이지의 무언가가 보이지 않으면 무시될 수 있다는 사실에 익숙할 것입니다. 페이지 설명과 같은 숨겨진 메타데이터가 이에 대한 좋은 예입니다. 사이트를 관리하는 사람들이 데이터를 쉽게 볼 수 없다면 쉽게 무시되고 구식이 될 수 있습니다.

이것은 리소스 힌트가 있는 실제 위험입니다. 코드가 숨겨져 있고 사용 중에 거의 감지되지 않기 때문에 페이지가 변경되고 리소스 힌트가 업데이트되지 않는 것이 매우 쉽습니다. 예를 들어 사용하지 않는 페이지를 미리 가져오는 것은 사이트의 성능을 향상시키기 위해 배치한 도구가 사이트에 적극적으로 해를 끼치고 있음을 의미합니다. 따라서 리소스 힌트를 최신 상태로 유지하기 위한 적절한 절차를 마련하는 것이 정말 중요합니다.

자원

"리소스 힌트 사양", W3C
"프리페칭으로 다음 페이지 탐색 속도 향상", Addy Osmani