Is consolidating/reducing HTTP requests worth the logistical complexity?

Question

Some examples:

• CSS image sprites
• Compiling JS needed on every webpage to one file
• Implementing lazy-loading for images
• Consolidating all meta information (username, CDN address, etc) into one request
• Specifically for AWS S3 browser uploads using signed policy documents: grabbing all the policy documents from the server in one request instead of one request per policy document

Some of these are easier to implement than others. Some of these need to be done only once, and others need to be done with every update or change. It seems that not doing any of this would be easier from a logistical perspective, however I'm also concerned about server performance.

I hope to avoid the boilerplate "avoid premature optimization root of all evil blah blah" comment here. My project is in the early stages, and I see now that establishing the wrong or inefficient API format would be difficult to change later. So, I'd like to ask for advice from those with experience in this matter:

1. How much loading time would be saved for the user for each request that's consolidated? (i.e. what is the overhead of each request excluding the time spent downloading the actual payload)

2. Does consolidating HTTP requests substantially reduce server usage/costs? If so, were you able to quantify it? (i.e. what is the overhead of each request excluding database access and "the code that actually does stuff")

Possibly relevant for the second part of the question: my back-end server is nginx serving Django Rest Framework running on Gunicorn hosted on EC2 behind the AWS Load Balancer. Static assets will be hosted on S3 and served from Cloudfront.

Answer 1

Your question is too broad to simply answer it yes/no.

Usually it depends.

My crystal ball is currently out of order, which makes it hard to give concrete advice ;)

My project is in the early stages

So, why bother with this question at all? The unspecific type of your question is a sign, that you do not have pain points. Otherwise your question would be like »My initial page load time is awful. How to deal with a ton of Javascript?«

This falls into the category of premature, i.e. without practical necessity. Of course it is always good to think about the future, but it is not necessary to think about it now. Start out straightforward. Do your application layout, have a look at webpack as a bundler. And get things going.

Does consolidating HTTP requests substantially reduce server usage/costs?

The obvious answer is yes. But again: Why bother?

As long as you aren't GoogleFacebookAmazon, why deal with their problems?

I understand the fear of technical debt; but look from it the other way: Say you hack together some Javascript alongside with a Django-Backend. The overall architecture is crap - but it works. When you have a successfull business, you are able to hire qualified engineers, which help you putting your application in shape.

If you take Amazon as an example, it was AFAIR a bunch of Perl-scripts, which did the job at the time. Of course you couldn't run Amazon today (only) on the scripts from then (besides it would be interesting to know if there are some artifacts still running). The system evolved over time.

Here are three takeaways:

1) Get a business going

2) There is no right way to do it.

3) YAGNI - Or do not optimize for a use case, which is irrelevant now.

Or if you want a concrete technical advice: Give a good first impression of your page:

• Deliver minimal Javascript which helps to bootstrap your application
• Few images on the landing page. There has to be a balance between delivering images (increase initial loadtime) and dynamically loading images (which could take some time on mobile internet). You have to choose between a slower or a maybe incomplete page, which effects both the first impression.
• Few/no animations - helps keeping the impression of a fast page; although processing power shouldn't matter as much as it did years ago.

Answer 2

Thomas's answer is great practical advice -- get the product built first.

From there, you need to understand why each potential optimization is recommended or popular before you can determine whether the product benefits from it. If you determine that a particular "optimization" is actually a potential improvement, try to quantify it, estimate the work, and make the business decision as usual.

For example: CSS image sprites.

What problem does it solve? When you use a lot of small images, the requests for those images are executed in serial, sometimes blocking other assets from coming through the pipe, and/or causing your user to see an unfinished page for a "long time."

How does the solution work? It combines a "core set" of images into a single request, which eliminates per-image request latency due to connection handshakes (in some cases), HTTP headers, the server request scheduling and processing, and so forth. On some browsers, or when the number of images of excessive, it also frees up the browser's connection pool, allowing it to start working on other assets in parallel.

How do I know when it's applicable to my application? When you load your site with a speed throttling tool (like Chrome's built in tool), configured to simulate a commonly low speed, and observe that the page takes "too long" to fully render particularly because there are "many" image requests, running in serial, blocking the "core assets" required for the page to be useful.

On the contrary, if you've got a small handful of images that aren't putting your pages over a usability threshold, or for images that are just big, it's probably not worthwhile to turn them into sprites.

How easy it to implement and maintain? That varies. If you're dealing with a bunch of decorative,"flavor" images that nearly never change, it's a small, one-time cost of running them through a tool. Don't even hesitate! If they're "content" images, it's a good deal more work..

And lastly, Is it worth it? ... armed with some actual cost-benefit information, it's just a business decision.

Consider each trick in that sort of respect.

What problem does it solve? How does it solve it? Is it applicable? What are the implementation and maintenance costs?

Finally, if you determine that the problem exists and the solution is applicable, but the cost is high, look for alternatives.

In the case of CSS image sprites, one alternative is to simply use fewer images...

Answer 3

Yes it is. But it's not about server load.

Sounds like you're building a single page application HTML5 and javascript libraries deserve a lot of credit for making this posible but the motivation to stick to one page isn't to spare the server. It's so the user doesn't have to wait while a second page loads.

Hidden content can be loaded while the user is staring at the first screen reading visible content. That way the user isn't punished when they click. They get instant content.

This approach actually lodes servers more in the long run since things that were never clicked on get loaded as well. But that's what it takes to create happy users.