Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Collect initiatorType use-cases #132

Open
nicjansma opened this issue Dec 15, 2017 · 2 comments
Open

Collect initiatorType use-cases #132

nicjansma opened this issue Dec 15, 2017 · 2 comments
Projects
Milestone

Comments

@nicjansma
Copy link
Contributor

nicjansma commented Dec 15, 2017

There are a few concerns and questions with initiatorType. Some examples:

  • CSS files are included via <link> tags so have a initiatorType="link", which causes confusion since there is a separate css initiatorType that is used if a CSS file downloaded something (e.g. fonts, background-image)
  • <link rel="preload"/> preloaded resources all have initiatorType="link" too
  • <video> tag behavior is inconsistent and may need to add clarity: VIDEO tag #130
  • <video poster=""> and <video src=""> would both be initiatorType="video"
  • etc

We are considering how to best address these concerns/questions. Is it better to fix and clarify V2 for cases that we can? Or should we design something differently for V3 that works better?

In order to make that decision, we should try to capture as many use-cases as possible -- what elements/things/etc trigger downloads and what info would consumers want about those downloads?

Example Use-Cases

These are the use-cases I know about:

  • <img src="...">
  • <img srcset="...">
  • <link rel="stylesheet" href="...">
  • <link rel="prefetch" href="...">
  • <link rel="preload" href="...">
  • <link rel="prerender" href="...">
  • <link rel="manfiest" href="...">
  • <script src="...">
  • CSS @font-face { src: url(...) }
  • CSS background: url(...)
  • CSS background: url(data:...) (shouldn't be downloaded)
  • CSS @import url(...)
  • CSS cursor: url(...)
  • CSS list-style-image: url(...)
  • <body background=''>
  • <input src=''>
  • XMLHttpRequest.open(...)
  • <iframe src="...">
  • <frame src="...">
  • <object>
  • <svg><image xlink:href="...">
  • navigator.sendBeacon(...)
  • fetch(...)
  • <video src="...">
  • <video poster="...">
  • <video src="..."> with Range: requests
  • <video><source src="..."></video>
  • <audio src="...">
  • <audio src="..."> with Range: requests
  • <audio><source src="..."></audio>
  • <picture><source srcset="..."></picture>
  • <picture><img src="..."></picture>
  • <picture><img srcsec="..."></picture>
  • <track src="...">
  • <embed src="...">
  • <a ping="..."> (too late?)
  • favicon.ico and other auto-downloads
  • UA extensions
  • EventSource

I'm probably missing some things in the above list.

@nicjansma nicjansma mentioned this issue Dec 15, 2017
@bluesmoon
Copy link

There are also downloads initiated from extensions that sometimes show up in ResourceTiming data. I think @jzyang has seen a bunch of strange url schemes show up in our resource timing data as well. I'll let her chime in with more info.

@igrigorik igrigorik added this to the Level 3 milestone Jan 18, 2018
@nicjansma
Copy link
Contributor Author

We'll keep this issue for Level 3 to decide how we can address some of the above confusion.

We'd also like to build tests for all existing Level 2 behavior. That is tracked in #138

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
3 participants