DevTools/Features/NetworkView
Status
| Network View | |
| Stage | Landed |
| Status | Complete |
| Release target | Firefox 23 |
| Health | OK |
| Status note | Landed in Firefox 23 |
Team
| Product manager | Kevin Dangoor |
| Directly Responsible Individual | Dave Camp |
| Lead engineer | ` |
| Security lead | ` |
| Privacy lead | ` |
| Localization lead | ` |
| Accessibility lead | ` |
| QA lead | ` |
| UX lead | ` |
| Product marketing lead | ` |
| Operations lead | ` |
| Additional members | ` |
Open issues/risks
`
Stage 1: Definition
1. Feature overview
For web developers, the "Network Panel" serves two primary purposes: digging into the details of specific requests and viewing load time performance. For this feature, the focus is on finding the desired request and digging in to the details. Depending on schedule and the intersection with other features, we may also include the load time performance aspect as well.
2. Users & use cases
Troubleshooting client/server communication
Web applications often involve a lot of client/server communication. It is increasingly common for a web server to send the initial HTML page and then all further communication is in the form of JSON responses. In order to make sure everything is working properly, the developer needs to be able to look at the request and response headers, cookies, and the request and response bodies.
Fixing requests that were made incorrectly
A web app could get the URL wrong (causing a 404 response from the server) or make an HTTP request on a page that is HTTPS (causing potential security issues for the user). The developer will want to be able to spot these problems quickly and fix them.
Finding resources that need optimization
One developer wanted to identify large images that could be optimized better. Other developers want to be able to spot JavaScript files that are too large or not gzipped. During development, the resources might not be in their final form (compressed/minified JS and CSS, for example) which is okay at that time. Most developers want their production servers to be as responsive as possible.
Tracking slow page loads
Page load time is very important for the user experience of a website. There a few ways to help users improve their page load times. You could provide a list of events that occur during loading or specific recommendations about ways to improve performance. However, a graphical timeline is a quick way for a user to visualize load time bottlenecks and slow loading resources.
3. Dependencies
`
4. Requirements
- Concise, sortable view
- View should be easily scannable
- Be able to view the details of a request
- search for requests (search or filter would be nice)
- Filter requests based on type
- highlight errors (4xx, 5xx statuses)
- highlight HTTP requests for HTTPS page
- Display load time statistics
- remote capable
Optional:
- request initiator
- View JSON data as an object
- View image thumbnails with the request for easy scanning
- web sockets support
- View customization
- View start time, completion time and duration for a request
- request timing details (how long did each phase of the request take?)
- support for console.timestamp
- Syntax highlighting for HTML/JS/CSS response bodies
- Resend a request
- Make a new request
- HAR export
Non-goals
`
Stage 2: Design
5. Functional specification
Activation
As long as the network view is open (and ideally when any developer tools are in use), network traffic is logged including request and response bodies. It's important that the information is available to the user when they want it, without a reload. If none of the tools are in use, then it is acceptable for performance reasons to not track the requests (or the bodies of the requests).
Reload Behavior
By default, reloading the page or navigating to another page will clear the network view. This would be acceptable behavior for the first iteration of the tool. The other tools also allow keeping the existing network state while navigating as an option.
Concise, Sortable View
Users need to be able to quickly find the request(s) they're looking for and to spot unexpected problems. The view should include the following fields
- URL
- HTTP method (GET, POST, etc)
- domain
- response code
- response size
- mime type
- remote IP address
Easy Scanning
To help users visually scan and identify the requests of interest, the display should highlight the most significant part of the URL, which would generally be the filename. Ideally, the display would adjust based on the unique parts of the URL. One possible approach:
- if the filename is unique among the URLs, just display that
- add as little of the path to the filename to create a unique value
- if the path and filename are not unique, look for query strings that differentiate the entries
Request Details
The request details should include basically the same information that is in the Web Console network panel. When the network panel is open the user should not have to explicitly turn on request/response body logging. Response body logging is expected when the user is viewing the network panel.
Request details should include a view of the cookies sent and set.
Search
The user should be able to search on the URL field. Searches should be case insensitive. Options could include regex matching and doing a filter rather than a search.
Request Filtering
Requests should be filterable on some common groupings:
- image
- stylesheet
- script
- xhr
- fonts
- websockets
- documents
- error/success
- JSON?
The list of filters provided could be tailored based on the responses present. So, if no web fonts or websockets are used, those filters need not be displayed.
Highlighting Errors
It should be easy to spot requests with problems. Specifically,
- 4xx and 5xx status codes
- HTTP requests made from an HTTPS page
Load Time Statistics
Include a simple textual display of load statistics. Number of requests, amount transferred, time to onload/DOMContentLoaded.
Remote Capable
Loading characteristics can be quite different on a mobile device, so this feature should be designed to allow eventual remote capability. Remoting is not required at this stage.
Copy/Paste
Copying events to the clipboard doesn't appear to produce very good results in the current popular developer tools. If there was a mechanism to select some network events and copy them, it would probably be most useful to just copy them in HAR format. This is optional behavior.
Web Sockets
Web Sockets should appear among the network requests and should be easily visible as web sockets. For the first round, there is no need to provide visibility into the data traversing the web socket.
SPDY
Requests made with SPDY should be flagged as such, ideally in both the table view and the details. This would help developers ensure that requests they expect to be made with SPDY are made with SPDY. This feature is optional for the first round, but would be nice to have if it's easy.
6. User experience design
shorlander and kdangoor spoke about the UX a bit. We both have a preference for a table in which the leftmost column has the URL and the view of the other columns is replaced by the details (more like Chrome/Opera and less like Firebug's current implementation). That style allows users to quickly step through request details. Firebug's current implementation which uses a disclosure triangle and expands the details below is acceptable, though.
Honza is open to certain changes in the net panel in Firebug as well.
- move method to a separate column (currently Firebug has it built into the URL field in the table)
- replace most of the table area rather than expanding requests in place
- thumbnail image on the left
Stage 3: Planning
7. Implementation plan
Work is ongoing here: https://github.com/firebug/httpmonitor
8. Reviews
Security review
`
Privacy review
`
Localization review
`
Accessibility
`
Quality Assurance review
`
Operations review
`
Stage 4: Development
9. Implementation
`
Stage 5: Release
10. Landing criteria
`
Feature details
| Priority | P1 |
| Rank | 3 |
| Theme / Goal | ` |
| Roadmap | Developer Tools |
| Secondary roadmap | ` |
| Feature list | Desktop |
| Project | ` |
| Engineering team | DevTools |
Team status notes
| status | notes | |
| Products | ` | ` |
| Engineering | ` | ` |
| Security | sec-review-needed | assigned to mgoodwin |
| Privacy | ` | ` |
| Localization | ` | ` |
| Accessibility | ` | ` |
| Quality assurance | ` | ` |
| User experience | ` | ` |
| Product marketing | ` | ` |
| Operations | ` | ` |
