Your system isn't slow because of your internet

"It's the office internet." It's the most common explanation when a business system is slow to open, and it almost never gets checked. The company switches internet providers, buys a new router, and the system is just as slow as before.

Slowness in a web system almost always has a measurable cause inside the system itself. Here are three we found while reviewing systems in production, with their real numbers, and how you can check yours without being a developer.

A 2 MB sign-in screen

In a time-tracking system, the sign-in screen weighed 2 MB of code in a single file: 583 KB already compressed, which is what actually travels over the network.

To show two fields and a button, every person downloaded the entire application: the reports, employee management, the catalogs, the dashboards. All of it before they could type their email.

It's like having to carry the whole inventory to the door before you can walk into a warehouse. On a good connection you barely notice. On a branch office network, a phone on mobile data, or an office with twenty people signing in at 9 a.m., you notice it every day.

Each screen loads when someone opens it

The fix has a technical name, per-page code splitting, but the idea is simple: the system is split into pieces and each screen is downloaded only when someone opens it. Someone who only logs their hours never downloads the reports screen.

Measured in production after the change, with two different instruments (downloading the file directly and the browser loading the screen), the sign-in screen now downloads 598 KB of code, 174 KB compressed. That's about 70% less than what used to travel over the network, on the screen everyone opens every day.

The double trip nobody sees

Reviewing that same sign-in flow turned up another detail: the system requested the user's data twice. Two parts of the application needed the profile and each one queried it on its own.

Nothing shows on screen. The user sees their name and gets in. But every repeated query is one more trip to the server, and in large systems those trips add up: ten duplicate queries on one screen are the difference between a screen that opens instantly and people getting used to waiting.

This kind of problem only shows up when someone counts the queries. Nobody reports it, because nobody knows it should be faster.

One trip to the server per keystroke

In another system, the admin panel search box queried the server on every keystroke. Typing an eight-letter name meant eight queries, and each one took between 160 and 270 milliseconds, measured in production.

The result feels like a "heavy" search box: letters appear late, the list flickers, results for the previous word arrive after those for the current one. People type more slowly so the system can keep up.

The fix was to filter what was already loaded in the browser, instantly, and query the server only when the person pauses. Same results, without the lag on every letter.

Why it's almost never the internet

All three cases have something in common: the problem was in how the system was built, not in the connection. And all three went unnoticed because the system worked. Nobody files a bug because a screen takes three seconds. It just becomes "the way the system is."

That cost doesn't show up on any invoice, but it gets paid. If twenty people wait a few seconds several times a day, every day, the system is charging the company hours of work every month. And the most expensive part isn't the time: it's that people stop using the system for anything that isn't mandatory and go back to the spreadsheet or to WhatsApp.

How to check yours in five minutes

You don't need access to the code. Chrome on a computer is enough:

• Open your system's sign-in screen and press F12 (or right-click → Inspect). Go to the Network tab.
• Reload the page with the tab open. At the bottom you'll see how much data was transferred. If the sign-in screen transfers more than 1 MB, it's worth asking why.
• Type into a search box in the system with the tab open. If a new request appears for every letter, you've found a place to improve.
• Look for repeated requests: the same request name two or more times when a screen opens is an extra trip.

None of these signs means your system is badly built. It means there's a measurement pending, and that the conversation with your vendor can be about numbers instead of impressions.

Questions for your vendor

• How much does the system's first screen weigh? If nobody knows, nobody has measured it.
• Does the system download all at once or screen by screen? A system that grows without being split gets slower with every new module.
• How many queries does it make when the main screens open? And how many of them are repeated.
• How is performance measured after each change? Today's speed doesn't guarantee the speed six months from now.

When you evaluate custom software, performance should come measured at delivery, just like the features. If you're comparing proposals, our guide on how much custom software costs explains what a serious one should include.

Slowness isn't debated, it's measured. If you want to know where your system's time goes, let's talk.