하위 도메인에서 링크 프리 페치를 사용할 수 있습니까?

10

간단한 랜딩 페이지에서 헤비급 단일 페이지 앱으로 클릭 할 때 성능 향상을 위해 다음과 같은 것을 사용하려고했습니다.

<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에 있습니다.

html link-prefetch

— 마로스
소스

프리 페치는 향후 탐색 속도를 높이는 데 사용됩니다. 간단한 설명 ( web.dev/link-prefetch )

— Mohammad Yaseer

예. 프리 페치는 향후 탐색 속도를 높여야합니다. 그렇다면 왜 내 속도가 빨라지지 않았습니까? 타이밍 그래프를 참조하십시오.

— Maros

하위 도메인 내용을 다른 도메인에 배치하고로드하는 데 동일한 시간이 걸리는지 확인할 수 있습니까? 서브 도메인이 아닌 경우 (예 : 다른 도메인) 사례가 작동하는 방식을 보여줌으로써 서브 도메인이 문제없이 나타날 수있는 것으로 보입니다. 하위 도메인에 문제가있는 경우 다음 단계는 Chrome 구성 설정을 조정하여이 작업을 수행하는지 확인하는 것입니다.

— Martin

또는 하위 도메인 및 / 또는 인디 도메인에 대해 동일한 로딩 시간이 Firefox Inspector 또는 Opera와 같은 유사한 도구 세트를 가진 다른 브라우저에 나타 납니까? 다른 엔진을 사용하는 다른 브라우저에서 동일한 타이밍 문제가 발생하는 경우 (더 이상 잘 모르고 더 이상 확실하지 않은 경우) 버그 일 수 있습니다. 크롬 버그 일 수 있다고 생각할 수 있습니다. 언급 된 시간 값이 다른 브라우저에서 눈에 띄게 다른 경우

— 마틴

0

<link rel=prefetch>웹 페이지에 추가 하면 브라우저가 사용자에게 향후 필요할 수있는 전체 페이지 또는 일부 리소스 (스크립트 또는 CSS 파일 등)를 다운로드하도록 지시합니다. 이렇게하면 First Contentful Paint 및 Time to Interactive와 같은 메트릭이 향상되고 후속 탐색이 즉시로드되는 것처럼 보일 수 있습니다.

프리 페치 힌트는 즉시 필요하지 않은 리소스에 추가 바이트를 소비하므로이 기술을 신중하게 적용해야합니다. 사용자에게 필요할 것이라고 확신 할 때만 리소스를 프리 페치하십시오. 사용자가 연결 속도가 느린 경우 프리 페치를 사용하지 마십시오. 네트워크 정보 API로이를 감지 할 수 있습니다.

프리 페치 할 링크를 판별하는 방법에는 여러 가지가 있습니다. 가장 간단한 방법은 현재 페이지에서 첫 번째 링크 또는 처음 몇 개의 링크를 프리 페치하는 것입니다. 이 포스트 https://web.dev/link-prefetch/ 에서 나중에 설명하는보다 정교한 접근 방식을 사용하는 라이브러리도 있습니다 .

— 모하마드 야 시어
소스

링크 프리 페치가 특정 상황에서 속도를 높이 지 않는 이유에 대한 설명을 찾고있었습니다. 하위 도메인, 서비스 워커 또는 다른 것 때문입니까? 스크린 샷을 보면 프리 페치에도 불구하고 브라우저가 콘텐츠를 다시 다운로드한다는 것을 알 수 있습니다.

— Maros

0

나는 단지 추측 할 수있다. 자신감있는 답변은 아마도 실험을 통해서만 당신에게서 찾을 수 있습니다. 설명 할 변수가 너무 많습니다. 그러나 여기 몇 가지 아이디어가 있습니다.

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

https://developer.mozilla.org/en-US/docs/Web/HTTP/Link_prefetching_FAQ#What_if_I.27m_downloading_something_in_the_background.3F_Will_link_prefetching_compete_for_bandwidth.3F

Mozilla를 사용하여 다운로드하는 경우 백그라운드 다운로드가 완료 될 때까지 링크 프리 페치가 지연됩니다.

크롬도 마찬가지라고 생각합니다.
방문 페이지를 루트 도메인으로 이동하려고 했습니까? 예, prefetch예상대로 작동하면 예-하위 도메인이 문제의 원인입니다. 그리고 GUI 메시지 Status Code: 200 (from prefetch cache)는 아마도 결함 일 것입니다. 최근 prefetch에 Chrome 의 동작에서 일부 사항이 변경되기 시작했습니다 . 그리고 일이 해결되었는지 아직 모르겠습니다. 기본적으로 그렇습니다 prefetch. 동일한 원점에서만 가능할 확률이 있습니다 .

https://docs.google.com/document/d/1bKGDIePAuF6YXmmrwM33LeLvtuCsla3vTspsxsNp-f8/edit

— x00
소스

답변을 읽은 후의 임의의 메모 : 랜딩 페이지에서 example.com으로 매우 느리게 이동하여 모든 리소스를로드 할 수있는 충분한 시간을 허용합니다. Chrome에서 서비스 작업자를 비활성화 한 상태에서 위의 테스트를 수행했습니다. crossorigin 속성은 다른 것을위한 것이라고 생각합니다. 나는 그것을 사용하려고 노력했지만 운이 없다. 최악의 경우 방문 페이지를 루트 도메인으로 이동하여 제안한 테스트를 수행합니다. 나는 대답이 나에게 도움이되기를 바랐다.

— Maros

1

FF를 사용해 보셨습니까? 위의 MDN 링크에서 : "Mozilla가 다른 호스트에서 문서를 프리 페치합니까? 이 구절은 구식이 될 수 있지만 여전히 그렇습니다. Chrome과의 동작이 다른지 아는 것이 좋습니다.

— x00

시도했지만 프리 페치 캐시보다 우선하는 것으로 보이는 서비스 워커를 비활성화 할 수 없었습니다. 그래도 다른 시도를 할 수 있습니다.

— Maros

@Maros, 어떻게 든 코드를 소유하고 있지 않거나 기술적 인 문제가 있습니까?

— x00

-1

하위 도메인이 아니며 도메인에서 리소스를 원할 경우 아래 코드를 추가해야합니다.

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

— divyang4481
소스