It's easy if it's a lightweight page and you have something faster than a 486. If it's heavy (lots of images, videos, downloads, etc) you can run out of bandwidth pretty quickly. However, that doesn't necessarily sink the ship!

Traffic shaping makes a big difference. Without it, the modem buffer quickly fills causing multi-second ping times. This easily leads to congestion collapse. TCP grows the receive window to large values, and the congestion avoidance algorithm doesn't do well when the feedback is delayed due to the latency. TCP starts sawtoothing, and you end up with occasional moments where a few pages get served, interspersed with so much loss that connections get dropped.

We used htb [1] which tightly controls the outbound traffic rate, preferring to drop packets instead of delay them. That prevents the modem's buffer from filling up, which keeps the latency down. This creates a smoother flow. Pages load slowly, but at least they keep loading, instead of wasting bandwidth on retries. It also prioritizes traffic: other services are guaranteed their minimum rates. We were using ssh through the line and didn't even realize we were getting hit until someone asked why the site was running slowly.

Newer algorithms are even better, especially for keeping jitter down, but htb is simple and vastly better than letting your router blast packets at full speed. OpenWRT and all the other open source router firmwares can do it these days. It improves things for even normal end-user uses, but if you're running a server at home, you really want to set up some QOS before someone hugs you to death.

[1] https://linux.die.net/man/8/tc-htb