0

I need an idea or concept how to reduce http request.
Conditions:
1000s of users(android/iphone) active
100s of small images (150kb/image) to be fetched

Simply by giving each image a hardcoded link, server will have to handle 100 * 1000 http requests. How could I minimize the requests?

7
  • 1
    Consider the usage of sprites. 150k/image seems a bit large, but good digital manipulation should be able to group and compress common usage images. Organization of images within the sprites would be key. Dec 23, 2015 at 16:22
  • 1
    Can you serve the images from somewhere else, like a CDN, or S3, or just a different server?
    – Erik Eidt
    Dec 23, 2015 at 16:22
  • 1
    HTTP 1.1 allows for multiple requests in the same TCP/IP connection. If you ensure that this is used, will it be enough? Dec 23, 2015 at 16:39
  • lol "small"​​​​ Dec 23, 2015 at 16:45
  • 3
    Can you ship these images with the app, or are we talking about something like profile pictures? Have you looked at re-encoding the images? Is this a problem you are having, or are worried about having? Dec 23, 2015 at 16:49

2 Answers 2

9

You can't decrease the request count. Not really. HTTP is one response per request (and this is one of the reasons for HTTP/2).

What you CAN do is decrease the number of requests that hit a given server.

I'd first solve this using a CDN for your images. This will make them the CDN's problem, one they're prepared to handle by distributing the images over many servers behind a load balancer. The easiest way to get started with a CDN is to host images on S3, as described in How to Configure Amazon S3 as a Content Delivery Network

Similarly, if you can't use a CDN service for some reason you can bake your own by adding a load balancer in front of your site and shedding requests for images onto a server designed to serve many long lived connections concurrently. NGINX is a good one. Again, you won't decrease requests, but you will decrease the requests that hit your app server and your users will get their images faster than if they had to wait in a request queue on an app server.

BTW, 150k is NOT a "small image." 100s of those per user is a 15 MB download. If you're doing this on mobile, you're gonna have a slow site and pissed off users no matter what you do.

2
  • 3
    I upvoted for "150k is NOT a 'small image.'" (because that's just ridiculous), but "You can't. Not really." isn't a good answer, especially when you give a solution yourself (CDN). Besides that, you could use sprite sheets, better caching, etc.
    – nanny
    Dec 23, 2015 at 16:35
  • Well you can't batch requests with HTTP. No matter what you do, you will have 100*1000 requests. I clarified that point. Dec 23, 2015 at 16:37
4

A sprite sheet is a series of images combined into a single image. This enables the content to be obtained once and cached by the user in a single request.

There are numerous tools able to create sprite sheets.

Stitches - an HTML5 based site sheet generator

Compass is a CSS preprocessor that also supports the creation of sprite sheets.

See this jsfiddle for implementation details:

Due to the large size of your individual images, your sprite sheet will be very large. Ensure your images are optimized for the web and set your caching headers correctly.

See Google Developers Web Fundamentals for image optimization for additional information on proper image optimization.

4
  • 1
    This is a great answer if the set of 100 images is common to all downloaders and unlikely to change over time. It may also be a great answer for some common, slow to change subset of the 100. Dec 23, 2015 at 17:05
  • 1
    And if this is the case then the images should probably be packed and distributed with the app in the first place. (Thus it seems unlikely to be the case.) Dec 23, 2015 at 17:08
  • 1
    @Matthew Mark Miller -- One could create a server side endpoint used to dynamically generate a sprite sheet while excluding the images the user doesn't have permission to view. On initial request, it could check to see if the image had already been generated for this user given the current permission configuration. If exists, serve it otherwise generate it, save it and serve it. Dec 23, 2015 at 17:30
  • One could do that, for sure -- but you're going to have inflated service and wait times as a side effect, along with spiky CPU load on the system building the sprite sheet. You would only want to do this if the sheets generated could be reused reliably -- e.g. the image set was not rapidly changing or highly stochastic. Dec 23, 2015 at 19:30

Not the answer you're looking for? Browse other questions tagged or ask your own question.