I have made changes recently to include base64 data uri strings in my css instead of image requests to external image files.
The issue this has caused is the increase in size from a stylesheet without data uri of 7KB to that 200KB+ with them. However I have significantly less http requests.
Is this ok - is the approach of large stylesheet better than one with multiple image requests?
Compare the size of the stylesheet to the total size of the images you base64'd. If it is the same or smaller, using the base64 URIs takes up less space (and download time). Generally, one large request is preferable over multiple smaller requests if the data being retrieved is identical and said requests are not concurrent.
200Kb is quite big for a stylesheet. Make sure you're serving it compressed if you're not already. If some/most of the data string images aren't used on most pages you might be better off splitting those into a separate stylesheet and including it only on pages where required.
How about you keep one stylesheet at the top of your document (in the head) that contains everything except for your base64 data. This will load quickly, and let the body of the document begin to load/display with these initial styles.
Then, create a second stylesheet at the bottom of the document (right before the closing /body tag) which contains the images as base64 data. That way, when this starts to load, at least the content is visible and mostly structured the way you want it.
Win-win??
Good luck!
Less requests, the better.
However, hostings limit the connection speed of a particular download stream. So, if your 200KB file can be downloaded in 2 secs, maybe 2 files of 100KB could be downloaded in 1 sec.
The rest is on you.
ADDED:
You can't gain any size reduction using compression. Your image data can't be compressed.
Related
I'm creating sort of a tutorial application and have to display images from firebase storage with a step-by-step tutorial. Currently I'm using the .getDownloadUrl function and am displaying the images using Cached Network Images(External library) with the URL. The images are replaced when the step is completed and it takes at least 2-3 seconds to load an image and can get quite irritating for a user. Also, to minimize latency I shifted the Cloud Storage location nearby to where a user would be, this improved the speed slightly. Is there a better way to display images, apart from storing the links on Cloud Firestore or saving all the URLs in one list at the start.
The most common approach is to compress/resize (or both) your images. By doing this you have a few options:
1. You can display the thumbnail by default and only load the full image (or load it in the background) when the user requests it (eg. they click on details about the tutorial)
2. Load a different version of the image depending on the screen size (you don't need to display an image meant for desktop on a mobile device)
3. Replace the old image with the compressed one. Depending on what the content is, you probably don't need images larger than 200kb, and that's being generous.
You could also consider storing your images using a next gen format, such as WebP as it is considered one of the most efficient image types. But, it's not yet supported on all devices, so you'd want to include a fallback type.
You said you're caching the images which is a good step to reduce load times. You also said you shifted the storage location to be closer to the users. You could also try to find a CDN that is even closer to your user's locations (probably diminishing returns).
You seem to be against storing the downloadUrls in your database. This would help as all you'd have to do is load the image, instead of ping the bucket for the url and then load it.
Another potential solution for your use case could be to download the images for this tutorial, as well as the next one so when the user clicks next the images are already downloaded.
Unfortunately there isn't a lot else you can do. There's a lot of data packed into an image and it takes some time to load and render it
I am trying to use different background images from session to session. So if users open my website in a different session(e.g. Close and reopen the browser or wait for half an hour), they will see a different background image.
Following is what I am currently doing.
I created a HttpHandler class that handles background.axd.
First it checks whether there is an entry called BackgroundIndex in the HttpContext.Current.Session, if not, it randomly chooses a image from the ones that I have, than stores its index into the Session object.
Then it compares the index with the value of the If-None-Match header, if they match, simply return a response with 304 Not Modified.
If not match, or there isn't a 'If-None-Match' header in the request, it writes the content of the image file to the response and return it with ETag header set to the index of the image.
At last, I set the background image of my website to background.axd in my CSS file.
The problem is, it works correctly, but not efficiently.
The image file for current session can be loaded from cache. But if the session changes, the browser will have to download the image from my server even if it has been downloaded before.
Also, the browser has to make additional request to check if the image in cache has been out of date.
Is there a better solution for this?
Sorry for my bad English.
I have created a centralized Image Application for all my other applications.I have created a http handler in that application for response. I pass the path of the image in the Query String and in response it find the image and add watermark and send it back in response. The purpose of this application is to watermark image and send back to the other applications. I am using asp.net with C#.Now I have a problem on two of my pages in the application I have 15 Image to show.For this purpose I have to call the handler 15 times. Is it possible to get response in a single call.Can I combined those images into one and send back response and using image sprite like feature i adjust the image on the page.All the images are of the same size.Am I Thinking in the right way or there is any other solution.
Thanks,
Shekhar
For this purpose I have to call the handler 15 times.
15 requests isn't that many especially if they are made from a clean page with low overall requests.
CSS sprites are undeniably a good practice, but they are usually created for sets of small, static images (great for buttons, icons, etc).
One consideration is the total size of the images. If the resulting sprite is very large, it may degrade the user's experience by making them wait for the entire large image to be processed and downloaded.
Another consideration is how much development effort and computational complexity is involved in determining which images to combine into one.
For a high-traffic reference site, consider the techniques that Yahoo Flickr uses:
Sprites for very small images
Data URIs for small thumbnails
Regular images served from multiple domains for everything else
On-demand loading for large lists of images
Summary
From your description, I would probably favor multiple requests combined with lazy loading and as much caching server-side (on the generation of the images) and client-side (via HTTP expire headers) as possible.
I think it's an encoded image in the CSS but why would they do that? Does it save space is it to stop people from stealing the images?
background:url(data:image/gif;base64,R0lGODlhEAAQAPQAACNBZ7TL5CpIbWV/nzNQdIukwW2Ip7TL5IGauJ630VFtjkdjhqfA2lp1lrHI4ZSsyHiRsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH/C05FVFNDQVBFMi4wAwEAAAAh/hpDcmVhdGVkIHdpdGggYWpheGxvYWQuaW5mbwAh+QQJCgAAACwAAAAAEAAQAAAFdyAgAgIJIeWoAkRCCMdBkKtIHIngyMKsErPBYbADpkSCwhDmQCBethRB6Vj4kFCkQPG4IlWDgrNRIwnO4UKBXDufzQvDMaoSDBgFb886MiQadgNABAokfCwzBA8LCg0Egl8jAggGAA1kBIA1BAYzlyILczULC2UhACH5BAkKAAAALAAAAAAQABAAAAV2ICACAmlAZTmOREEIyUEQjLKKxPHADhEvqxlgcGgkGI1DYSVAIAWMx+lwSKkICJ0QsHi9RgKBwnVTiRQQgwF4I4UFDQQEwi6/3YSGWRRmjhEETAJfIgMFCnAKM0KDV4EEEAQLiF18TAYNXDaSe3x6mjidN1s3IQAh+QQJCgAAACwAAAAAEAAQAAAFeCAgAgLZDGU5jgRECEUiCI+yioSDwDJyLKsXoHFQxBSHAoAAFBhqtMJg8DgQBgfrEsJAEAg4YhZIEiwgKtHiMBgtpg3wbUZXGO7kOb1MUKRFMysCChAoggJCIg0GC2aNe4gqQldfL4l/Ag1AXySJgn5LcoE3QXI3IQAh+QQJCgAAACwAAAAAEAAQAAAFdiAgAgLZNGU5joQhCEjxIssqEo8bC9BRjy9Ag7GILQ4QEoE0gBAEBcOpcBA0DoxSK/e8LRIHn+i1cK0IyKdg0VAoljYIg+GgnRrwVS/8IAkICyosBIQpBAMoKy9dImxPhS+GKkFrkX+TigtLlIyKXUF+NjagNiEAIfkECQoAAAAsAAAAABAAEAAABWwgIAICaRhlOY4EIgjH8R7LKhKHGwsMvb4AAy3WODBIBBKCsYA9TjuhDNDKEVSERezQEL0WrhXucRUQGuik7bFlngzqVW9LMl9XWvLdjFaJtDFqZ1cEZUB0dUgvL3dgP4WJZn4jkomWNpSTIyEAIfkECQoAAAAsAAAAABAAEAAABX4gIAICuSxlOY6CIgiD8RrEKgqGOwxwUrMlAoSwIzAGpJpgoSDAGifDY5kopBYDlEpAQBwevxfBtRIUGi8xwWkDNBCIwmC9Vq0aiQQDQuK+VgQPDXV9hCJjBwcFYU5pLwwHXQcMKSmNLQcIAExlbH8JBwttaX0ABAcNbWVbKyEAIfkECQoAAAAsAAAAABAAEAAABXkgIAICSRBlOY7CIghN8zbEKsKoIjdFzZaEgUBHKChMJtRwcWpAWoWnifm6ESAMhO8lQK0EEAV3rFopIBCEcGwDKAqPh4HUrY4ICHH1dSoTFgcHUiZjBhAJB2AHDykpKAwHAwdzf19KkASIPl9cDgcnDkdtNwiMJCshACH5BAkKAAAALAAAAAAQABAAAAV3ICACAkkQZTmOAiosiyAoxCq+KPxCNVsSMRgBsiClWrLTSWFoIQZHl6pleBh6suxKMIhlvzbAwkBWfFWrBQTxNLq2RG2yhSUkDs2b63AYDAoJXAcFRwADeAkJDX0AQCsEfAQMDAIPBz0rCgcxky0JRWE1AmwpKyEAIfkECQoAAAAsAAAAABAAEAAABXkgIAICKZzkqJ4nQZxLqZKv4NqNLKK2/Q4Ek4lFXChsg5ypJjs1II3gEDUSRInEGYAw6B6zM4JhrDAtEosVkLUtHA7RHaHAGJQEjsODcEg0FBAFVgkQJQ1pAwcDDw8KcFtSInwJAowCCA6RIwqZAgkPNgVpWndjdyohACH5BAkKAAAALAAAAAAQABAAAAV5ICACAimc5KieLEuUKvm2xAKLqDCfC2GaO9eL0LABWTiBYmA06W6kHgvCqEJiAIJiu3gcvgUsscHUERm+kaCxyxa+zRPk0SgJEgfIvbAdIAQLCAYlCj4DBw0IBQsMCjIqBAcPAooCBg9pKgsJLwUFOhCZKyQDA3YqIQAh+QQJCgAAACwAAAAAEAAQAAAFdSAgAgIpnOSonmxbqiThCrJKEHFbo8JxDDOZYFFb+A41E4H4OhkOipXwBElYITDAckFEOBgMQ3arkMkUBdxIUGZpEb7kaQBRlASPg0FQQHAbEEMGDSVEAA1QBhAED1E0NgwFAooCDWljaQIQCE5qMHcNhCkjIQAh+QQJCgAAACwAAAAAEAAQAAAFeSAgAgIpnOSoLgxxvqgKLEcCC65KEAByKK8cSpA4DAiHQ/DkKhGKh4ZCtCyZGo6F6iYYPAqFgYy02xkSaLEMV34tELyRYNEsCQyHlvWkGCzsPgMCEAY7Cg04Uk48LAsDhRA8MVQPEF0GAgqYYwSRlycNcWskCkApIyEAOwAAAAAAAAAAAA==);}
It is called data url and contains an image in the GIF-format in this example. It saves you an extra HTTP request, but can only be used for smaller files, since some browsers limit the size of data urls. It has downsides though: Caching does not work properly for those images. Additionally, browser support is not very good at the moment (IE7 lacks support and IE8 limits the size to 32KB).
It's to reduce HTTP requests. Personally I'm not a fan of this technique as it's more troublesome to maintain and update, and images can't download concurrently.
It's the whole contents of the gif in base64 format. It's just as easy to save the image as a file from the browser, so security is not the reason, but saving an extra HTTP request as others said.
it's basically a base64 output of that image , it used to save http requests and speed thing up
i think if you read this , you will get all needed information
When you should use base64 for images
When doing webpages, the client/browser decides if it updates a file like an image or .css or .js or if it takes that from the Cache.
In case of .aspx page it is the server who decides.
Sure, on IIS level or also using some HttpModule techniques I can change the headers of requests to tell the client if and how long a file should be cached.
Now, I do have a website where the .aspx goes hand-in-hand with a corresponding .js. So, perhaps I have some jQuery code in the .js which accesses an element in the .aspx. If I remove that element from the .aspx I would also adapt the .js. If the user goes to my page he will get the new .aspx but he might still get the old .js, leading to funny effects.
My site uses lots of scripts and lots of images. For performance reasons I configured in the IIS that those files "never" expire.
Now, from time to time a file DOES change and I want to make sure that users get the update files.
In the beginning I helped myself by renaming the files. So, I had SkriptV1.js and SkriptV2.js and so on. That's about the worst option since the repository history is broken and I need to adapt both the references and the file name.
Now, I improved here and change only the references by using Skript.js?v=1 or Skript.js?v=2.
That forces the client to refresh the files. It works fine, but still I have to adapt the references.
Now, there is a further improvement here like this:
<script type='text/javascript' src='../scripts/<%# GetScriptLastModified("MyScript.js") %>'></script>
So, the "GetScriptLastModified" will append the ?v= parameter like this:
protected string GetScriptLastModified(string FileName)
{
string File4Info = System.Threading.Thread.GetDomain().BaseDirectory + #"scripts\" + FileName;
System.IO.FileInfo fileInfo = new System.IO.FileInfo(File4Info);
return FileName + "?v=" + fileInfo.LastWriteTime.GetHashCode().ToString();
}
So, the rendered .js-Link would look like this to the client:
<script type='text/javascript' src='/scripts/GamesCharts.js?v=1377815076'></script>
The link will change every time, when I upload a new version and I can be sure that the user immediately gets a new script or image when I change it.
Now, two questions:
a) Is there a more elegant way to achieve this?
b) If not: Has someone a guess how big the performance overhead on the server would be? There can be easily 50 versioned elements on one page, so for one .aspx the GetScriptLastModified would be invoked 50 times.
Looking forward to a discussion :)
There are a few different answers to this question.
First of all, if you have files which only change every once in a while, set the Expires and Cache-Control headers to expire in one year. Only if the files truly never expire should you say that they never expire. You're seeing the issues with saying "never expire" right now.
Also, if you are having performance issues on your site from serving up lots of images and JavaScript, the commonly accepted solution is to use a CDN (Content Delivery Network). There are many different providers and I'm sure that you can find one that meets your budget. You'll also save money in the long run as the CDN will offload a great deal of I/O and CPU time from IIS. It's astounding how big of a difference it can make.
Lastly, one way to make sure that users are getting the latest for your files which almost never change is to implement some sort of versioning scheme in your assets URLs to make cache busting happen. There are many different ways to do this, but one (very naive) way to do it is to have a version number that increases every time you deploy to your site.
E.g. all your asset URLs will look like /static/123/img/dog_and_pony.jpg
Then, next time you deploy to your site, you increase the version number so that it's "124". You would need some way to keep track of the version, dynamically injecting it into asset URLs, as well as making sure that the version number changes every time you deploy. The idea being that anything referencing this asset should automatically know the new version number.
In terms of performance, it's an admirable goal to never need the user to refresh or have to download the same thing twice. But sometimes it's just a lot less hassle, and if users are only refreshing everything periodically, that's probably okay for most websites.
Hope this helps.