The "Localhost" Bias The "Localhost" Bias We've all been there. On your machine, the API responds in 5ms. The UI updates instantly. You click "Submit," the modal closes, and you move on to the next ticket. Status: Done. ✅ 5ms Done But on a user's 4G connection in a subway tunnel, that same API call takes 2 seconds. 2 seconds Because you tested on localhost (Gigabit Fiber), you missed critical race conditions: 🖱️ The Double-Click Bug: The user clicks "Submit" twice because "nothing happened," charging their credit card twice.
🔄 The Infinite Spinner: The loader gets stuck forever because a packet was dropped.
🏎️ Race Conditions: Data arrives out of order, overwriting the user's input. 🖱️ The Double-Click Bug: The user clicks "Submit" twice because "nothing happened," charging their credit card twice. The Double-Click Bug 🔄 The Infinite Spinner: The loader gets stuck forever because a packet was dropped. The Infinite Spinner 🏎️ Race Conditions: Data arrives out of order, overwriting the user's input. Race Conditions Your app feels fast because you are cheating. 0ms latency is a lie. 0ms latency is a lie The Wrong Solution: time.sleep()I often see tests that look like this: The Wrong Solution time.sleep() # ❌ Don't do this
page.click("#submit")
time.sleep(2) # Simulating "network lag"
expect(page.locator(".success")).to_be_visible() # ❌ Don't do this
page.click("#submit")
time.sleep(2) # Simulating "network lag"
expect(page.locator(".success")).to_be_visible() Why this fails: sleep() just pauses the test execution script. The browser engine itself is still blazing fast. It doesn't simulate network queues, slow handshakes, or constrained bandwidth. You aren't testing the network; you're just making your test suite slower. Why this fails sleep() The Right Solution: Network Throttling (CDP) The Right Solution: Network Throttling (CDP) To test this properly in automation, you need to talk directly to the browser engine. You need to tell Chrome: "Pretend you are on a terrible 50kb/s connection." Pretend you are on a terrible 50kb/s connection. We can do this using the Chrome DevTools Protocol (CDP) within Playwright. This forces the browser to handle packet delays and loading states exactly as a real user would experience. Chrome DevTools Protocol (CDP) The Code (Python + Playwright) The Code (Python + Playwright) Here is how to inject a "Bad 3G" connection into your test: from playwright.sync_api import Page, expect

def test_slow_network_handling(page: Page):
    # 1. Connect to Chrome DevTools Protocol (CDP)
    # This gives us low-level access to the browser
    client = page.context.new_cdp_session(page)

    # 2. 🧨 CHAOS: Emulate "Bad 3G"
    # Latency: 2000ms (2 seconds)
    # Throughput: 50kb/s (Very slow)
    client.send("Network.emulateNetworkConditions", {
        "offline": False,
        "latency": 2000, 
        "downloadThroughput": 50 * 1024,
        "uploadThroughput": 50 * 1024
    })

    page.goto("https://myapp.com/search")

    # 3. Trigger the slow action
    page.fill("#search-box", "Playwright")
    page.click("#search-btn")

    # 4. Resilience Assertion

    # Check 1: Does the UI prevent double submission?
    expect(page.locator("#search-btn")).to_be_disabled()

    # Check 2: Does the user get immediate feedback?
    expect(page.locator(".loading-spinner")).to_be_visible() from playwright.sync_api import Page, expect

def test_slow_network_handling(page: Page):
    # 1. Connect to Chrome DevTools Protocol (CDP)
    # This gives us low-level access to the browser
    client = page.context.new_cdp_session(page)

    # 2. 🧨 CHAOS: Emulate "Bad 3G"
    # Latency: 2000ms (2 seconds)
    # Throughput: 50kb/s (Very slow)
    client.send("Network.emulateNetworkConditions", {
        "offline": False,
        "latency": 2000, 
        "downloadThroughput": 50 * 1024,
        "uploadThroughput": 50 * 1024
    })

    page.goto("https://myapp.com/search")

    # 3. Trigger the slow action
    page.fill("#search-box", "Playwright")
    page.click("#search-btn")

    # 4. Resilience Assertion

    # Check 1: Does the UI prevent double submission?
    expect(page.locator("#search-btn")).to_be_disabled()

    # Check 2: Does the user get immediate feedback?
    expect(page.locator(".loading-spinner")).to_be_visible() Why this matters: This test proves your UI provides feedback. If a user clicks a button and waits 2 seconds with no visual feedback, they will assume the app is broken. Why this matters **But wait, what about Mobile Apps?📱
\ The script above is perfect for automated CI pipelines running Chrome. But CDP has a major limitation:It doesn't work on a physical iPhone or Android device. It doesn't work on a physical iPhone or Android device If you are a Mobile Developer or manual QA, you can't "attach Playwright" to the phone in your hand to simulate a subway tunnel. The Manual Alternative (System-Level Proxy) The Manual Alternative (System-Level Proxy) To test latency on a real device without writing code, you need a System-Level Proxy that sits between your phone and the internet. System-Level Proxy You can use desktop tools like Charles Proxy (if you enjoy configuring Java apps and firewalls), or you can use a cloud-based tool like Chaos Proxy (which I'm building). Chaos Proxy Chaos Proxy It allows you to simulate "Subway Mode" (2s latency) on any device—iPhone, Android, or Laptop—just by connecting to a Wi-Fi proxy. "Subway Mode" (2s latency) The Workflow: The Workflow: Create a "Chaos Rule" (e.g., Latency = 2000ms).
Connect your phone to the proxy via QR code. Create a "Chaos Rule" (e.g., Latency = 2000ms). Connect your phone to the proxy via QR code. 3. Watch your app struggle (and then fix it). Summary Summary Stop trusting Localhost. It hides your worst bugs.
Automated: Use Playwright + CDP to inject latency in your E2E tests.
Manual/Mobile: Use a Chaos Proxy to test resilience on physical devices. Stop trusting Localhost. It hides your worst bugs. Stop trusting Localhost Automated: Use Playwright + CDP to inject latency in your E2E tests. Automated Manual/Mobile: Use a Chaos Proxy to test resilience on physical devices. Manual/Mobile Happy Testing! 🧪 If you found this useful, check out my previous post: Stop Testing Success. Kill the Database. Stop Testing Success. Kill the Database. Stop Testing Success. Kill the Database.

This story contains AI-generated text. The author has used AI either for research, to generate outlines, or write the text itself. 

The "Spinner of Death": Why Localhost Latency is Lying to You

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

AI Wrote Your Tests. Variables Keep Them Alive.

Decreasing Latency for High Frequency Crypto Arbitrage Trading

Exploring the World of Distributed Systems: PACELC Theorem or Why CAP Is Not Enough

bLatency and finality in different cryptocurrencies

Competitive Gamer Secret: ARP (Address Resolution Protocol)

How to Cash 300K Requests per Second in a High-Volume Surveillance System

AI Wrote Your Tests. Variables Keep Them Alive.

Decreasing Latency for High Frequency Crypto Arbitrage Trading

Exploring the World of Distributed Systems: PACELC Theorem or Why CAP Is Not Enough

bLatency and finality in different cryptocurrencies

Competitive Gamer Secret: ARP (Address Resolution Protocol)

How to Cash 300K Requests per Second in a High-Volume Surveillance System

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps