Работает ли предварительная выборка ссылок между поддоменами?

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, я все еще вижу долгую задержку на вкладке сети Chrome, поскольку 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 есть различные виды кэшей: кэш предварительной выборки, кэш на диске и кэш памяти. Дисковый кеш и кеш-память работают очень быстро (время загрузки 5 мс и 0 мс). Однако предварительная выборка кеша довольно бесполезна, иногда время загрузки составляет 300 мс. Могу ли я получить техническое объяснение, почему это происходит? Это ошибка с Chrome? Я на Chrome 79.0.3945.117.

html link-prefetch

— Maros
источник

Предварительная выборка используется для ускорения навигации в будущем, см. Краткое объяснение от ( web.dev/link-prefetch )

— Мохаммед Ясир

Да, предварительная выборка должна ускорить будущие навигации. Тогда почему это не ускорило это в моем случае? Смотрите временные графики.

— Maros

Можете ли вы попробовать разместить содержимое субдомена в другом домене и проверить, требуется ли для загрузки то же время? Вы, кажется, нарисовали, что субдомен может быть проблемой, не показывая ее, показывая, как работает не субдомен (то есть другой домен). Если субдомен является проблемой, то следующим шагом будет выяснить, есть ли настройка Chrome для настройки, которая будет делать это, или

— Martin

Или одинаковое время загрузки для поддоменов и / или доменов инди появляется в других браузерах с похожими наборами инструментов, такими как Firefox Inspector или Opera? Если та же проблема с синхронизацией возникает в других браузерах, которые используют разные движки (я не уверен, что делают и не делают больше), как вы ссылаетесь, это может быть ошибкой - я могу полностью полагать, что это может быть ошибка Chrome если эти отмеченные значения времени заметно отличаются в других браузерах.

— Мартин

0

При добавлении <link rel=prefetch>на веб-страницу браузер загружает целые страницы или некоторые ресурсы (например, скрипты или файлы CSS), которые могут понадобиться пользователю в будущем. Это может улучшить показатели, такие как First Contentful Paint и Time to Interactive, и часто может привести к тому, что последующие навигации будут загружаться мгновенно.

Подсказка предварительной выборки потребляет дополнительные байты для ресурсов, которые не нужны немедленно, поэтому эту технику нужно применять вдумчиво; Предварительная загрузка ресурсов возможна только тогда, когда вы уверены, что они понадобятся пользователям. Не рекомендуется выполнять предварительную выборку, когда пользователи используют медленные соединения. Вы можете обнаружить это с помощью API Network Information.

Существуют разные способы определения ссылок на предварительную загрузку. Самый простой - это предварительная выборка первой ссылки или первых нескольких ссылок на текущей странице. Есть также библиотеки, которые используют более сложные подходы, объясненные позже в этом посте - 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, предварительная загрузка ссылок будет отложена до завершения любых фоновых загрузок.

Я думаю, что то же самое касается Chrome.
Вы пытались переместить свою целевую страницу в корневой домен? Если, да, и 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 для чего-то другого. Я попытался использовать это, и не повезло. В худшем случае я проведу тестирование, которое вы предлагаете, переместив целевую страницу в корневой домен. Я надеялся, что ответ здесь спасет меня от работы.

— Марос

1

Вы пробовали FF? Из приведенной выше ссылки MDN: «Будет ли Mozilla выполнять предварительную выборку документов с другого хоста? Да. Ограничения по тому же источнику для предварительной выборки ссылок не существует. Ограничение предварительной выборки только URL-адресами с одного и того же сервера не повысит безопасность браузера». Этот отрывок может быть устаревшим, но все же. Будет полезно узнать, отличаются ли они своим поведением в Chrome.

— x00

Я пытался, но не смог отключить сервисных работников, которые, казалось, имели приоритет над кэшем предварительной выборки. Я могу дать ему еще одну попытку, хотя.

— Марос

@ Maros, почему-то у тебя нет кода, или возникла какая-то техническая проблема?

— x00

-1

Вы должны добавить код ниже, если вы не используете поддомен и хотите получить ресурс из домена.

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

— divyang4481
источник