간단한 랜딩 페이지에서 헤비급 단일 페이지 앱으로 클릭 할 때 성능 향상을 위해 다음과 같은 것을 사용하려고했습니다.
<link rel="prefetch" href="https://example.com" as="document" />
<link rel="prefetch" href="https://example.com/app.js" as="script" />
<link rel="prefetch" href="https://example.com/app.css" as="style" />
방문 페이지가 하위 도메인에있을 때 눈에 띄는 성능 향상이없는 것 같습니다. 말해봐 https://subdomain.example.com
.
나는 방문에 대한 링크를 클릭하면 https://example.com
, 나는 여전히 크롬 네트워크 탭에서 긴 지연을 참조 app.js
하고 app.css
로드 :
프리 페치를 비활성화 한 동일한 리소스는 다음과 같습니다.
총 시간이 거의 같습니다.
프리 페치 캐시로로드 된 자산 중 하나에 대한 요청 헤더 :
일반:
Request URL: https://example.com/css/app.bffe365a.css
Request Method: GET
Status Code: 200 (from prefetch cache)
Remote Address: 13.226.219.19:443
Referrer Policy: no-referrer-when-downgrade
응답:
accept-ranges: bytes
cache-control: max-age=31536000
content-encoding: gzip
content-length: 39682
content-type: text/css
date: Mon, 06 Jan 2020 21:42:53 GMT
etag: "d6f5135674904979a2dfa9dab1d2c440"
last-modified: Mon, 06 Jan 2020 20:46:46 GMT
server: AmazonS3
status: 200
via: 1.1 example.cloudfront.net (CloudFront)
x-amz-cf-id: dO3yiCoPErExrE2BLYbUJaVye32FIJXXxMdI4neDGzGX9a6gcCDumg==
x-amz-cf-pop: LAX50-C1
x-amz-id-2: 1O0LmihxpHIywEaMQWX7G3FDAzxtH9tZq1T/jeVLMzifFSJSIIJSS6+175H61kKdAq6iEbwfs2I=
x-amz-request-id: AF35C178092B65D4
x-cache: Hit from cloudfront
의뢰:
DNT: 1
Referer: https://example.com/auth/join
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.117 Safari/537.36
내 질문은 : Chrome에서 프리 페치 캐시가 사용되었다고 표시하면 왜 콘텐츠 다운로드 시간이 중요한가요?
Chrome에는 프리 페치 캐시, 디스크 캐시 및 메모리 캐시와 같은 다양한 종류의 캐시가있는 것 같습니다. 디스크 캐시와 메모리 캐시는 매우 빠릅니다 (5ms 및 0ms로드 시간). 그러나 프리 페치 캐시는 때로는 300ms 다운로드 시간으로 쓸모가 없습니다. 왜 이런 일이 발생했는지 기술적 인 설명을 얻을 수 있습니까? Chrome의 버그입니까? Chrome 79.0.3945.117에 있습니다.
답변
<link rel=prefetch>
웹 페이지에 추가 하면 브라우저가 사용자에게 향후 필요할 수있는 전체 페이지 또는 일부 리소스 (스크립트 또는 CSS 파일 등)를 다운로드하도록 지시합니다. 이렇게하면 First Contentful Paint 및 Time to Interactive와 같은 메트릭이 향상되고 후속 탐색이 즉시로드되는 것처럼 보일 수 있습니다.
프리 페치 힌트는 즉시 필요하지 않은 리소스에 추가 바이트를 소비하므로이 기술을 신중하게 적용해야합니다. 사용자에게 필요할 것이라고 확신 할 때만 리소스를 프리 페치하십시오. 사용자가 연결 속도가 느린 경우 프리 페치를 사용하지 마십시오. 네트워크 정보 API로이를 감지 할 수 있습니다.
프리 페치 할 링크를 판별하는 방법에는 여러 가지가 있습니다. 가장 간단한 방법은 현재 페이지에서 첫 번째 링크 또는 처음 몇 개의 링크를 프리 페치하는 것입니다. 이 포스트 https://web.dev/link-prefetch/ 에서 나중에 설명하는보다 정교한 접근 방식을 사용하는 라이브러리도 있습니다 .
답변
나는 단지 추측 할 수있다. 자신감있는 답변은 아마도 실험을 통해서만 당신에게서 찾을 수 있습니다. 설명 할 변수가 너무 많습니다. 그러나 여기 몇 가지 아이디어가 있습니다.
prefetch
브라우저에 대한 힌트 입니다. 브라우저는 임의의 이유로 무시할 수 있습니다. 그보다 우선 순위가 가장 낮습니다.- 예를 들어 브라우저 설정을 확인하십시오
Menu/Settings/Advanced/Privacy and security/Preload pages for faster browsing and searching
(또는 이와 유사한 것). - 만일 당신이 만일 당신이 모바일 인터넷을 사용하고 있다면 그것은 또한 문제가 될 수 있습니다.
https://www.technipages.com/google-chrome-prefetch - 방문 페이지에서
example.com
? - 서버 로그를 확인하여
prefetch
요청을 수신하는지 확인하십시오 . -
서버가
prefetch
요청 에 대한 응답으로 이상한 헤더를 설정했는지 확인하십시오 . 예Cache-Control: no-cache
. 네, 당신이있는 것으로 확인cache-control: max-age=31536000
서버가 동일한 요청 (음 … 서로 다른 헤더를 보낼 경우 그래서, 정말 이상한 것, 거의 같은 적어도 캔에 거기에 당신이 그들이 말했다하지 않았다 적어도 및prefetch
요청 임을 나타내는 일부 헤더 일 수 있지만 이상한 일이 발생합니다. -
crossorigin
속성 을 추가해야 할 것입니다 . 예 :<link rel="prefetch" href="https://example.com/app.css" as="style" crossorigin />
여기 https://www.w3.org/TR/resource-hints/ 이 예제를 찾을 수 있습니다
<link rel="preconnect" href="//example.com"> <link rel="preconnect" href="//cdn.example.com" crossorigin>
귀하의 사건과 관련이 있지만 불행히도 설명이 없습니다.
-
질문의 원래 버전에서 서비스 근로자에 대해 언급했습니다. 서비스 직원이 무언가를 다운로드하거나 직접 다운로드하는 경우 문제가 될 수도 있습니다. 우선 순위가 가장 낮기 때문에
prefetch
Mozilla를 사용하여 다운로드하는 경우 백그라운드 다운로드가 완료 될 때까지 링크 프리 페치가 지연됩니다.
크롬도 마찬가지라고 생각합니다.
-
방문 페이지를 루트 도메인으로 이동하려고 했습니까? 예,
prefetch
예상대로 작동하면 예-하위 도메인이 문제의 원인입니다. 그리고 GUI 메시지Status Code: 200 (from prefetch cache)
는 아마도 결함 일 것입니다. 최근prefetch
에 Chrome 의 동작에서 일부 사항이 변경되기 시작했습니다 . 그리고 일이 해결되었는지 아직 모르겠습니다. 기본적으로 그렇습니다prefetch
. 동일한 원점에서만 가능할 확률이 있습니다 .https://docs.google.com/document/d/1bKGDIePAuF6YXmmrwM33LeLvtuCsla3vTspsxsNp-f8/edit
답변
하위 도메인이 아니며 도메인에서 리소스를 원할 경우 아래 코드를 추가해야합니다.
<link rel="preconnect" href="https://example.com">