canmove, Confirmed users, Bureaucrats and Sysops emeriti
1,093
edits
DevTools/Features/TimelineView: Difference between revisions
no edit summary
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
{{FeatureStatus | {{FeatureStatus | ||
|Feature name=Network | |Feature name=Network View | ||
|Feature stage= | |Feature stage=Planning | ||
|Feature health=OK | |Feature health=OK | ||
}} | }} | ||
| Line 9: | Line 9: | ||
}} | }} | ||
{{FeaturePageBody | {{FeaturePageBody | ||
|Feature overview= | |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===== Tracking | |||
|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. | 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 requirements=# | |||
|Feature requirements=# Concise, sortable view | |||
# View | # View should be easily scannable | ||
# Be able to view the details of a request | # 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 errors (4xx, 5xx statuses) | ||
# | # highlight HTTP requests for HTTPS page | ||
# Display load time statistics | # Display load time statistics | ||
# remote capable | |||
Optional: | Optional: | ||
# | # web sockets support | ||
# View JSON data as an object | # View JSON data as an object | ||
# View image thumbnails with the request for easy scanning | |||
# 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 | # Resend a request | ||
# Make a new request | # Make a new request | ||
|Feature functional spec=* Request/response | # HAR export | ||
* JSON | |||
* | |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: | |||
# 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. | |||
|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 | |||
}} | }} | ||
{{FeatureInfo | {{FeatureInfo | ||