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

Hundreds of data urls will freeze the network tab

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

Issue description

Cameron of Box.com reported a bug to me: they have hundreds of data urls and it locks up the network tab.
 
Owner: eustas@chromium.org
Status: Assigned
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.
I agree that seeing data:urls in the network panel is useful. +1 for adding an option.
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.
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.
> 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?
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.
>> (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.
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. ;)
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.
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
We've planned to remove data urls long time ago...
For slowness we have another bug -  Issue 316092 
@igrigorik: scalability point taken, we were thinking of a better timeline there. What about this very issue though? Any hints?
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