New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 3 users

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Nov 2013
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment
link

Issue 313845: Hundreds of data urls will freeze the network tab

Reported by pdr@chromium.org, Oct 31 2013 Project Member

Issue description

Cameron of Box.com reported a bug to me: they have hundreds of data urls and it locks up the network tab.
 

Comment 1 by pfeldman@chromium.org, Nov 1 2013

Owner: eustas@chromium.org
Status: Assigned

Comment 3 by eustas@chromium.org, Nov 7 2013

Status: Fixed

Comment 4 by phistuck@gmail.com, Nov 7 2013

Huh?
What is the justification for that (beside this edge case of a bug)?
Can you at least make it optional?
Logging every URL/resource load is useful.

Comment 5 by lakenen-...@box.com, Nov 7 2013

I agree that seeing data:urls in the network panel is useful. +1 for adding an option.

Comment 6 by paul.ir...@gmail.com, Nov 7 2013

I've personally always felt data uris dont make sense in network panel, as
they aren't treated as real network requests.

what value does seeing data:uris in network panel provide? one use case is:
I want to see all images, regardless of how those assets are delivered.
However, resources currently solves that use case.

What other reasons would you want to keep them in there?

Comment 7 by phistuck@gmail.com, Nov 7 2013

I want to see all resource requests, ordered with timing and any other relevant information in one place.

Comment 8 by phistuck@gmail.com, Nov 7 2013

Especially since reading recently published blog posts or articles about the inefficiency of data URLs, I want to know if anything loads them at a critical path.

Comment 9 by pfeldman@chromium.org, Nov 7 2013

If that is so, in order to address this, we would need to add another Audit
that would check for efficient use of data: urls. Or maybe it is easier to
fix data urls than to introduce the audit.

Comment 10 by pfeldman@chromium.org, Nov 7 2013

> What is the justification for that (beside this edge case of a bug)?

The justification is that "Network" panel is inspecting network specifics. I.e. requests made against servers or entries loaded off cache. When you "load" something from data url, this means that data has already been loaded or generated. Why would it end up in "Network" panel?

Comment 11 by phistuck@gmail.com, Nov 7 2013

I agree with you about the semantics, however, you have transformed it into being the Network panel. It is the evolution of the Resources panels which used to show all resource requests.
Renaming it is fine, but keep the useful functionality. Ordered request list with timing information is a needed asset.
If we are on the subject of semantics, any non HTTP/HTTPS/FTP URLs should be hidden as well (so chrome, blob, filesystem and file should be dropped. They are, after all. non network requests. document.location.href = "fsdfds://fdsfds" also shows a request and it should not) and RTC communication should show up.

Frankly, I would not bother with dropping anything. Adding an option for the data URL cases is good enough, but even better would be making the Developer Tools feature not freeze upon a large amount of data URL requests.

Maybe just rename the panel to better describe what it shows and keep its functionality as is and deal appropriately with edge cases such as the basis of the issue.

Comment 12 by pfeldman@chromium.org, Nov 7 2013

>> (so chrome, blob, filesystem and file should be dropped. They are, after all. non network requests. document.location.href = "fsdfds://fdsfds" also shows a request and it should not) and RTC communication should show up.

That's all good points, I have no idea what blob and filesystem are doing there, I'd rather have RTC there. chrome is arguable, not sure what to do about it.

>> Maybe just rename the panel to better describe what it shows and keep its functionality as is and deal appropriately with edge cases such as the basis of the issue.

How would you describe what it shows today then? "Loaders"? That might sound too confusing.

Comment 13 by phistuck@gmail.com, Nov 7 2013

Since resources is taken ;) this is problematic, I agree.
"Resources" should really be "Resource tree" or "Page tree", or "Content tree" or "Contents" and "Network" should be "Resources", or "Resource requests", or "Requests".
(While "Request" may be associated with HTTP requests, it is also a request from either cache, the file system, the web user interface, a blob, an external protocol or anything else. A page requests resources and the browser sometimes denies its requests. I think it makes sense)

Naming is always hard, but do not drop features due to a confusing name. ;)

Comment 14 by pfeldman@chromium.org, Nov 8 2013

Cc: igrigo...@chromium.org
I think people associate Network with latency and that is why they spend time on that panel. When you want your app to load fast, you traditionally focus on network first. That's why it is important to see things that hit servers and chaches there. +igrigorik for his perspective on data urls, blobs, webrtc represented in Network tab. My take on it is that since they are either not associated with high latency (data, blobs) or are not actionable (webrtc), they don't really belong there.

Since loading is now complex + web is dynamic, latency analysis shifts to timeline, but that is a different story.

Comment 15 by igrigo...@google.com, Nov 8 2013

Putting the data urls and other stuff aside for one second, aren't we missing the larger problem.. Namely, network tab not being able to handle large number of requests on it? Given that its now not unusual to find pages with 200, 300, and even 500+ requests [1], it seems like that we ought to fix the root problem? 

[1] http://bigqueri.es/t/whats-the-distribution-of-requests-per-page/21/3

Comment 16 by eustas@chromium.org, Nov 9 2013

We've planned to remove data urls long time ago...
For slowness we have another bug -  Issue 316092 

Comment 17 by pfeldman@chromium.org, Nov 9 2013

@igrigorik: scalability point taken, we were thinking of a better timeline there. What about this very issue though? Any hints?

Comment 18 by igrigo...@google.com, Nov 9 2013

I have found it useful in the past to be able to see where data: URIs are being (ab)used - e.g. some sites inline image previews then load the full image via XHR or similar technique. Today, this is easy to detect in the network panel, and without it, it'd be much harder.. really, the only way (short of view-source) would be to open/record timeline and look for decodes? With that in mind, given that inlining is mostly a network workaround/optimization, it seems to make sense to surface it in network panel. Also, conceptually it's not that different from SPDY/HTTP 2.0 server push (in fact that's what inlining is), and I would expect to see push resources show up in the network panel.. so that's another +1 for keeping data uri's there?

Sign in to add a comment