Network debugging

This tutorial guides you through analyzing network requests from a mobile device with WebDebugX’s network tooling. You will learn how to monitor traffic, analyze request performance, intercept and modify requests, and solve common network problems.

Overview

WebDebugX’s network tooling gives you comprehensive request analysis, helping you:

• Monitor every network request in real time
• Analyze the details of requests and responses
• Measure network performance metrics
• Intercept and modify requests
• Simulate different network conditions
• Track down network-related problems

Tip: network debugging works for every supported debugging target, including iOS Safari, iOS WebView, Android Chrome and Android WebView.

Starting network debugging

1. Connect your mobile device to the computer
2. Select the target you want to debug in WebDebugX (a browser or an app)
3. Click the Network tab to open the network panel
4. Make sure Record network is enabled (it is on by default)

The request list

The main view of the network panel shows every captured request.

Columns

• URL: the request URL
• Method: the HTTP method (GET, POST, and so on)
• Status: the HTTP status code and status text
• Type: the resource type (document, script, stylesheet, and so on)
• Size: the response size
• Time: when the request started
• Duration: how long the request took to complete

Filtering requests

1. Use the search box to search by URL, status code or content type
2. Use the filter buttons to narrow to specific request types (XHR, JS, CSS, and so on)
3. Use the status filter to narrow to specific states (successful, failed, redirected, and so on)
4. Use the time range filter to view a particular window

Sorting requests

1. Click a column header to sort by it
2. Click the same header again to toggle ascending / descending
3. By default requests are sorted by time, newest first

Request detail

Click any request in the list to view its details.

Request information

• URL: the full request URL
• Method: the HTTP method
• Status: the HTTP status code and status text
• Protocol: the protocol in use (HTTP/1.1, HTTP/2, and so on)
• Remote address: the server IP address and port
• Referrer: the URL of the page that made the request

Request headers

• Every request header is shown as a key-value pair
• You can view them raw or formatted
• You can copy a single header or all of them

Request body

For requests that carry a body (POST, PUT, and so on):

• Formatted automatically by content type (JSON, form data, and so on)
• Viewable raw or formatted
• The body content can be copied

Response information

• Status: the HTTP status code and status text
• Headers: every response header
• Content: the response body, formatted by content type
• Size: the response size (compressed and uncompressed)
• Time: response timing information

Timing breakdown

• Queueing: time spent waiting in the queue
• Stalled: time the request was blocked (waiting for a connection, for instance)
• DNS lookup: time spent resolving DNS
• Connecting: time spent establishing the connection
• TLS negotiation: time spent on the TLS handshake (HTTPS only)
• Sending: time spent sending the request data
• Waiting: time spent waiting for the server to respond
• Receiving: time spent receiving the response data
• Total: total time from start to finish

Network performance analysis

Performance metrics

• Total requests: the number of requests during page load
• Total transfer size: the combined size of every request
• Average response time: the average across all requests
• Maximum response time: the response time of the slowest request
• Request type distribution: how requests break down by type

Waterfall

1. Above the request list, switch to the Waterfall view
2. The waterfall shows each request’s timeline and its individual phases
3. Different colours represent different phases (DNS lookup, connecting, waiting, and so on)
4. It makes dependencies and parallelism between requests immediately visible

Performance suggestions

1. Above the request list, click Performance suggestions
2. Review the suggestions for the current network activity
3. Suggestions may include enabling compression, combining resources, using a CDN, and so on
4. Click a suggestion to see a detailed explanation and how to implement it

Request interception and modification

WebDebugX lets you intercept and modify network requests, which is very useful for testing and debugging.

Enabling interception

1. In the debugging interface, click More tools (the three dots)
2. Choose Request interception
3. Enable the Intercept requests option
4. Add interception rules (URL pattern, request method, content type, and so on)

Modifying a request

1. When a request is intercepted, WebDebugX pauses it
2. You can modify the request headers, body or URL
3. Click Continue to send the modified request
4. Click Block to block the request

Mocking a response

Return a mock response without sending the actual request:

1. In the interception settings, choose Mock response
2. Set the response status code, headers and body
3. When a matching request occurs, WebDebugX returns the mock response
4. This is very useful for testing error handling or offline behaviour

Network condition simulation

WebDebugX lets you simulate different network conditions to test how the application behaves.

Preset conditions

1. In the debugging interface, open the Throttling dropdown in the Network panel
2. Choose a preset (Offline, 2G, 3G, 4G, and so on)
3. WebDebugX simulates the bandwidth and latency of the selected condition
4. Reload the page or the app and observe the behaviour under the network limit

Custom conditions

1. In the Throttling dropdown, choose Custom
2. Set the download speed, upload speed and latency (round-trip time)
3. Name the profile and save it — it appears in the throttling dropdown for reuse
4. Reload the page and observe how it loads under that condition

Tip: slow-network problems usually only show up on first paint. Pair the throttled reload with Performance analysis to see which resource is actually holding up the first screen.

Offline mode

Choosing Offline cuts the page off from the network entirely, which lets you verify:

• Whether offline caching (Service Worker, AppCache) actually works as intended
• Whether error messages and retry logic behave correctly when requests fail
• Whether the page reconnects on its own once the network comes back