Why Your App is Still Slow After Optimization?

You have optimized your database queries, your API responds in under 100ms, and your CDN is correctly configured. Yet users still report slow load times, and performance monitoring shows latency spikes that appear without explanation.

The issue often lies outside your application or infrastructure. Two core network protocols can directly impact performance. TCP congestion control may make inefficient decisions about how data flows under varying conditions, and BGP routing can send traffic along longer, suboptimal paths across the internet.

This is not the result of poor coding or misconfigured servers. It is a reminder that the behavior of foundational internet protocols can override even the best optimizations, and understanding them is critical to reducing unpredictable latency.

What is TCP Congestion?

Every TCP connection needs to answer a fundamental question: how fast should data be sent? Send too slowly and you waste available bandwidth. Send too quickly and you'll overwhelm the network, causing packet loss and retransmissions.

TCP congestion control algorithms handle this decision automatically, but their choices directly impact your application's performance in ways that can override all your code-level optimizations.

There are two types of TCP congestion control algorithms, but they approach the problem very differently.

1. CUBIC

Most internet servers still use CUBIC, a loss-based congestion control algorithm.

CUBIC's strategy is straightforward: increase the data transmission rate until packet loss occurs, then back off and gradually increase again.

This approach works well for bulk data transfers, but it creates problems for modern applications. CUBIC treats packet loss as the primary signal of network congestion, which means it needs to overfill network buffers to detect when to slow down. Those overfilled buffers translate directly into increased latency for your application.

When a user clicks on a video thumbnail, CUBIC might send the first few data packets quickly, but as it ramps up transmission speed, it begins filling intermediate network buffers. Your video data sits in these buffers, adding 100-200ms of delay before reaching the user's device. From your monitoring perspective, the server responded quickly, but the user experiences the additional buffer delay.

CUBIC is probably the best, most robust congestion control algorithm available. But, as internet bandwidths grow and wireless represents a larger share of network links, TCP doesn't perform as desired.

2. BBR (Bottleneck Bandwidth and RTT)

Google's BBR takes a different approach. Instead of waiting for packet loss to detect congestion, BBR actively measures available bandwidth and round-trip time to calculate the optimal sending rate.

BBR continuously estimates two key metrics: the maximum bandwidth available on the path to the destination, and the minimum round-trip time. Using these measurements, it calculates the ideal transmission rate without needing to fill network buffers.

Real-world use-cases show significant improvements. Companies handling large-scale video delivery report 21% performance improvements when switching from CUBIC to BBR. More importantly for interactive applications, BBR maintains much lower latency because it doesn't rely on buffer overflow to detect congestion.

The difference becomes particularly noticeable for mobile users, where network conditions change frequently and CUBIC's loss-based approach struggles to adapt quickly to varying bandwidth and latency conditions.

BGP (Border Gateway Protocol) Routing

While TCP congestion control controls how fast data moves, BGP decides the path that data takes across the internet. BGP is the backbone of the internet because it allows one network to talk to another. It is the protocol that connects thousands of independent networks such as ISPs, cloud providers, and data centers, making the internet work as a whole.

BGP works at the application layer of the OSI model but runs on top of TCP using port 179. Its main job is to let networks advertise which IP prefixes they can reach and to choose a path for traffic between them.

The problem is that BGP focuses on reachability, not performance. As long as the data can reach its destination, BGP considers the task complete even if the chosen route is longer or slower than required.

What is BGP Hijacking ?

Your application might send data to a user in London, and you'd naturally expect that data to take a direct path through European internet infrastructure. But BGP routing decisions made by various network operators along the way might send that traffic through entirely different paths.

Data could travel from your London server to a user in London by way of internet exchanges in Frankfurt, Amsterdam, and back to London. Each additional hop adds latency, and each network transition introduces potential performance variations that your application has no control over.

More concerning are BGP hijacking incidents, where malicious or misconfigured network operators advertise routes for IP address ranges they don't actually control. When this happens, traffic intended for your servers gets redirected through unintended networks which leads to unexpcted results.

What This Means for Application Performance ?

TCP congestion control and BGP routing can amplify each other’s weaknesses. When BGP shifts traffic to a new path, the latency and bandwidth may differ significantly from what the TCP algorithm has been tuned for.

CUBIC, which relies on packet loss and recovery cycles, struggles in this situation. It interprets the sudden change as congestion and cuts transmission speed, even if the new path has sufficient capacity. Performance remains poor until CUBIC slowly recalibrates.

BBR adapts more effectively. Instead of relying on past behavior, it continuously measures bandwidth and round-trip time. When BGP reroutes traffic, BBR quickly adjusts its sending rate to the new path’s conditions.

These interactions explain why users may see latency spikes even when your servers and APIs are healthy. Geographic variations often stem from BGP routing choices rather than application issues, and mobile users are especially affected since variable bandwidth and latency expose CUBIC’s limitations. BBR’s active measurement approach tends to handle such conditions more gracefully.

Summary

You can’t control BGP routing choices, but understanding them helps with architecture and troubleshooting. Enabling BBR at the server level often improves performance, especially for mobile and real-time applications, since it’s built into modern Linux kernels and requires no code changes.

For routing resilience, diversify across multiple CDNs or cloud regions so that a single BGP issue doesn’t affect all users. Geographic redundancy ensures alternative paths are available when routing problems occur.

Monitoring should go beyond application response times. Metrics like TCP retransmissions, round-trip latency, and regional performance differences reveal when protocol-level issues are degrading user experience.

The takeaway is that network protocols can override even the best application optimizations. The internet’s core protocols were never designed for today’s performance demands, yet they still decide how data flows. Recognizing their influence helps you build more resilient systems and debug issues that aren’t in your code.