Troubleshoot slow Ramp performance on a corporate network

Overview

Note: This page is meant to be shared with your IT team. The instructions below are for IT teams troubleshooting corporate network performance.

If users report that Ramp loads slowly in a desktop browser on your corporate network, use this guide to compare connections and identify affected hosts. Proxies and HTTPS inspection, including services reached through a VPN, can downgrade browser connections to HTTP/1.1, limiting concurrent requests and delaying JavaScript assets and API calls.

HTTP/1.1 alone does not establish a proxy cause. Compare protocols and loading times before changing network settings.

Compare connections and request timing

Work with an affected user to compare the corporate connection with an alternate connection approved by your organization. Use the same device, browser, account, workflow, and cache settings for both. Confirm that the alternate connection uses a different network path; switching Wi-Fi may still use the corporate proxy.

  1. Open Chrome DevTools and select Network before loading the affected page. Keep network throttling off.
  2. Right-click the request table's column headings and enable Protocol and Domain.
  3. Check JS requests for static assets and Fetch/XHR requests for API calls separately. Record each affected host and protocol: http/1.1, h2 (HTTP/2), or h3 (HTTP/3). The main page's protocol does not describe every request.
  4. Select slow requests and open Timing. Record Queueing, Stalled, connection setup, response waiting, and download delays. See Chrome's timing reference for what these phases mean.
  5. Measure how long the page takes to display its data and respond to input. Repeat several times on each connection using the same loading task.

Use fresh network requests when checking protocols. Cached requests or missing protocol values do not establish HTTP/1.1.

Review the corporate network configuration

If affected hosts use HTTP/1.1 on the corporate connection but HTTP/2 or HTTP/3 with faster loading on the alternate connection, review those hosts' proxy and inspection policies. If protocols match but loading differs, review routing and timing delays instead.

Enable or preserve HTTP/2 on the VPN/proxy path where supported. HTTP/2 supports concurrent requests over one connection; HTTP/3 is not required. Not all VPN/proxy configurations support HTTP/2, so check your deployed product's capabilities.

If the path cannot support HTTP/2, configure a routing bypass for these Ramp hosts:

api.ramp.com
app.ramp.com
logos.ramp.com
sgmnt-t.ramp.com
receipts.ramp.com
customer-documents.ramp.com
assets.ramp.com
cdn1.static.ramp.com
cdn2.static.ramp.com
cdn3.static.ramp.com
cdn4.static.ramp.com

Add another affected host: Review the exact hostname and comparison results. Verify Ramp ownership using your organization's approved evidence sources and obtain your organization's IT/security approval for that host's routing bypass before adding it.

Use *.ramp.com instead only if your IT/security team approves bypassing the VPN/proxy path for all current and future Ramp subdomains.

The bypass must route traffic to the selected hosts outside the VPN/proxy path that downgrades connections. A firewall allow rule alone does not change that route. Keep the bypass scoped to the selected hosts rather than disabling the VPN or security controls globally.

Verify the network change

Repeat the comparison after applying a change. Check fresh requests for each affected static-asset and API host to confirm the browser uses h2 or h3. Compare several loading times against the earlier corporate results and alternate connection, using the same test settings.

Confirm with the affected user that page data and controls work. If loading remains slow, use the comparison results to investigate the remaining request timing delays. A protocol change alone does not guarantee an improvement.