DevTools/Features/NetworkView

Please use "Edit with form" above to edit this page.

Status

Network View
Stage	Definition
Status	`
Release target	`
Health	OK
Status note	`

{{#set:Feature name=Network View

|Feature stage=Definition |Feature status=` |Feature version=` |Feature health=OK |Feature status note=` }}

Team

Product manager	Kevin Dangoor
Directly Responsible Individual	Kevin Dangoor
Lead engineer	`
Security lead	`
Privacy lead	`
Localization lead	`
Accessibility lead	`
QA lead	`
UX lead	`
Product marketing lead	`
Operations lead	`
Additional members	`

{{#set:Feature product manager=Kevin Dangoor

|Feature feature manager=Kevin Dangoor |Feature lead engineer=` |Feature security lead=` |Feature privacy lead=` |Feature localization lead=` |Feature accessibility lead=` |Feature qa lead=` |Feature ux lead=` |Feature product marketing lead=` |Feature operations lead=` |Feature 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

1. Concise, sortable view
2. View should be easily scannable
3. Be able to view the details of a request
4. search for requests (search or filter would be nice)
5. Filter requests based on type
6. highlight errors (4xx, 5xx statuses)
7. highlight HTTP requests for HTTPS page
8. Display load time statistics
9. remote capable

Optional:

1. web sockets support
2. View JSON data as an object
3. View image thumbnails with the request for easy scanning
4. View customization
5. View start time, completion time and duration for a request
6. request timing details (how long did each phase of the request take?)
7. support for console.timestamp
8. Syntax highlighting for HTML/JS/CSS response bodies
9. Resend a request
10. Make a new request
11. HAR export

Non-goals

`

Stage 2: Design

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:

1. if the filename is unique among the URLs, just display that
2. add as little of the path to the filename to create a unique value
3. 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.

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

`

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

` {{#set:Feature open issues and risks=` |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. |Feature users and 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. |Feature dependencies=` |Feature requirements=# Concise, sortable view

1. View should be easily scannable
2. Be able to view the details of a request
3. search for requests (search or filter would be nice)
4. Filter requests based on type
5. highlight errors (4xx, 5xx statuses)
6. highlight HTTP requests for HTTPS page
7. Display load time statistics
8. remote capable

Optional:

1. web sockets support
2. View JSON data as an object
3. View image thumbnails with the request for easy scanning
4. View customization
5. View start time, completion time and duration for a request
6. request timing details (how long did each phase of the request take?)
7. support for console.timestamp
8. Syntax highlighting for HTML/JS/CSS response bodies
9. Resend a request
10. Make a new request
11. HAR export

|Feature non-goals=` |Feature functional spec==== 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:

1. if the filename is unique among the URLs, just display that
2. add as little of the path to the filename to create a unique value
3. 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. |Feature ux 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

|Feature implementation plan=` |Feature security review=` |Feature privacy review=` |Feature localization review=` |Feature accessibility review=` |Feature qa review=` |Feature operations review=` |Feature implementation notes=` |Feature landing criteria=` }}

Feature details

Priority	P1
Rank	7
Theme / Goal	`
Roadmap	Developer Tools
Secondary roadmap	`
Feature list	Desktop
Project	`
Engineering team	DevTools

{{#set:Feature priority=P1

|Feature rank=7 |Feature theme=` |Feature roadmap=Developer Tools |Feature secondary roadmap=` |Feature list=Desktop |Feature project=` |Feature engineering team=DevTools }}

Team status notes

	status	notes
Products	`	`
Engineering	`	`
Security	`	`
Privacy	`	`
Localization	`	`
Accessibility	`	`
Quality assurance	`	`
User experience	`	`
Product marketing	`	`
Operations	`	`

{{#set:Feature products status=`

|Feature products notes=` |Feature engineering status=` |Feature engineering notes=` |Feature security status=` |Feature security health=` |Feature security notes=` |Feature privacy status=` |Feature privacy notes=` |Feature localization status=` |Feature localization notes=` |Feature accessibility status=` |Feature accessibility notes=` |Feature qa status=` |Feature qa notes=` |Feature ux status=` |Feature ux notes=` |Feature product marketing status=` |Feature product marketing notes=` |Feature operations status=` |Feature operations notes=` }}