​​The Raw Speed of the Web

When you optimize for speed over everything else the web can get pretty fast.

The trick is in 2022 to manage or pay attention to everything that your page has in it. Everything that the server sends to the browser can be measured.

We’ll be taking a look at this page:

In order to send this page to the browser a request was made. Then the browser received it’s response from the server, in this case it was an HTML page.

This HTML page told us to download these additional elements, namely these images and css from the same site and a couple of images from other sites

Some of the images and css were downloaded in parallel which saved time.

For some sites literally every item has to show up before anything can be rendered. But for this page the rendering happens as soon as the HTML is loaded, so while the browser times how many milliseconds it takes to finish loading our reader can start reading as soon as text shows up on the screen.

For human perception most anything that happens below 13ms is perceived as instantaneous. But anything that happens below 100ms is “almost instantaneous” and that’s our target for webpages, almost instantaneous.

So how fast does this page load? The browser reports this page loads in around 127ms (milliseconds) and the total time is 140ms. So I tried checking the time with a stopwatch but my hand reaction time wasn’t fast enough, I was reacting in around 390ms, but I could perceive that it did take some amount of time. Thankfully I had a high speed camera via my smartphone, I could record a high speed video and count how many frames it took in between pressing enter and the rendering to finish. The video frame rate is 240fps (frames per second) and the number of frames it took to display is approximately 83. So this means the page took around 346ms to display, my reaction time was pretty close but the eye (and brain) is actually faster than the hand.

Right before enter is pressed

Right after enter is pressed

The first visual indicator appears in the toolbar

The browser starts painting

The browser asks the display to continue painting

The site first starts appearing

The text is dim, this may be the browser rendering a different color of text because the background is white

The site is finally rendered

Interpretation of Results

One hundred milliseconds is the goal, we might not reach the goal and that’s ok as well. In reaching for the goal we might be able to substantially improve the user experience. There are several things outside of our control such as internet speed and device speed.

There are actually more things outside our control than inside. As we can see from the above analysis. Not only is internet speed variable but it depends how the interconnection from server to client is handled. Also there are a very wide range of devices that can access the web, many of which can introduce slowdown themselves.

So let’s focus on the things we can control. How long it takes to process a request from receiving it, to sending it down the wire. Once we do send it down the wire we have the ability to measure how much data is sent.

Let’s focus on processing speed on the server first. When we get a request we should take careful note of where the response actually comes in and how long it takes till we start doing something with it. I Read This Week uses an nginx reverse proxy and Go on the server and I was surprised at how quickly the response goes from server to nginx to Go to gin’s middleware and finally to my route definition. It didn’t take nearly as long as I thought. Originally I was reading the article off the database. But after adding a cache layer I could return the request as quickly as possible.

The next thing we can optimize is what comes down the wire. This requires us to determine exactly what the webpage or webapp does. If it’s a blog or news site where the primary information that the person requesting will be textual, then it makes the most sense to encode it as HTML and send it down, it doesn’t get much faster.

If it’s an app then the smallest thing that can possibly be displayed should come over first to show the user at least something is happening. The rest of the app will be ready in a few seconds and both the user and us expect the user to use the app for a few minutes.

Sometimes the flow of a single page app can be “faked” using a website with multiple pages and if attention is paid to all of the above the speed can be just as performant across the board. As long as the user’s perception is kept in mind. So in essence the main point, which has been a long winded way of getting to the title of this post, is how it is possible to achieve “The Raw Speed of the Web.”

Conclusion

The goal is to determine what exactly the app needs to do. In I Read This Weeks’s case it’s to take signups and show blog posts. That’s great because raw web was made to do stuff like this. One issue that comes up is state. Where will the state be stored because when a user signs up we have more than one question. In a single page app state can be stored in JavaScript and synced up to a server via a REST API that sends JSON back and forth.

In our case however, the state is stored the same way, in a database, but each page transition only asks one question for each page. What we might miss out on is a slick animation that transitions from one question to the next but in the context of raw speed it’s actually quicker to the end user to do a full server hop because there’s no animation to slow us down.

In the case of displaying a post the only thing that has to come down the wire is the actual post with HTML and text.

The one thing I haven’t talked about so far is images. Yes, we should optimize images. The issue with images is the larger in millimeters the image is the longer it will take to load. The image should be large enough to display in size to get the point across and just enough resolution to look good. Reduce the size on disk to just enough, but no more. If needed a link can be provided on the image to a higher quality image and perhaps this should be a common practice.

Will the web get faster? The web only needs to be as fast as the person looking at the page. We don’t need to get up to the theoretical speed limit of light if the person on the other end is a human with perception times that can only perceive a page up to a certain limit. Once we go faster we are in the range of video speed and then the same rules apply.

If you enjoyed this post consider subscribing to the author, Abe Massry