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.
Related
When utilising Firebase Storage to store imagery, for example, user avatars, is there a way that you can request a smaller, thumbnail sized serving of the image?
I have searched Google and documentation and I have been unable to come up with a result. Currently my app utilising Firebase Storage URLs experiences a minor delay prior to loading images due to the fact that it I am requesting large images to fill tiny avatars.
Is there a resource I am overlooking that specifies the available parameters for this URL? (of which token & alt are two I'm aware of).
Thank you for the assistance in advance.
Auto-resizing images upon read is not a feature of Firebase Storage. The typical solution is to create variants of the images during upload, for example through the Resize Images extension.
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 have installed and customized WooCommerce Product Pages on my WordPress site, but one of the product category pages takes about 7 seconds on average to load. Other category pages load in around 3 seconds. I am struggling to find the reason for this. There are less products on this page than other pages and less sub-categories. I have installed plug-ins such as 'W3TC' and 'Better WordPress Minify' but it hasn't made much difference.
Has anyone else experienced an issue like this and if so, would you mind sharing how you resolved it?
Any help would be greatly appreciated.
Thanks
Using caching plugins is fine and dandy but the reason these pages load slowly is simply the data model that WordPress uses, post-types and the metadata look-ups. The only way to truly get speeds up is good hosting and turning on Object Cache on the server.
We enable this on a WP-Engine site and it was night and day. 12 seconds turned into 2.5 seconds.
Object caching
Object Caching is designed to capture queries to the database and store them in memory. This allows you to run an "expensive" query - a query that takes a long time - one time, and then reuse the results again. When used properly, Object Caching can give your site a speed boost by reducing the time that is spent accessing the database. Please note that this change can take a while to take effect.
There can be many reasons for a WordPress pages to load slower. But you problem seems to be unique.
Here are some useful tips by which you can speed up your page loading:
Optimize Your Images
The page on which you are having issue might have High Resolution Images.
Avoid displaying flash on your Page
Avoid too many advertisements
Cut off the Unnecessary ads from the page.
Do not use inline cascading style sheets
Besides utilizing inline cascading style sheets make a CSS file and call up file on all page of your site that will likewise help in repressing download speed.
Put stylesheets at the top - Put scripts at the bottom
Utilize javascript at the bottom of the page this will serve to load up your page fast. When web browser download javascript it will finish downloading your internet site data, and so any analog downloading will end while browser request Javascript downloading.
Use CSS Sprites
A CSS sprite is an an image comprised of other images used by your design as something of a map containing the coordinates of all the images. Some clever CSS is used to show the proper section of the sprite when your design is loaded.
Here you do not have to load multiple images which are used on you site. Just loading of a single sprite image will do all your work.
Limit Your External Scripts
There might be a issue that external script is being loading on that page. You need to check and limit the same.
Add LazyLoad to your images
You can use this technique to load the page part by part.
Control the amount of post revisions stored
I saved this post to draft about 8 times.
WordPress, left to its own devices, would store every single one of these drafts, indefinitely.
Turn off pingbacks and trackbacks
Let me know if the problem resolves using these tips for you site.
The list of suggestions that WisdmLabs mentions above is great!
However, I'm not sure if you've seen the plugin for Wordpress called W3 Total Cache. It has a load of built in functionality to automatically improve the performance of your Wordpress web pages.
It's free and worthwhile using if you are looking to improve the performance across your whole site.
https://wordpress.org/plugins/w3-total-cache/
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.
Why does Google Analytic request a GIF file?
Is it because the GIF allows access to more data than JavaScript alone. Is it to get the IP address of the user?
Google's javascript has to transmit the details of your page view to their servers some how. Ajax cannot be used across domains, so the only way to submit the information is to request a file from a Google server, passing the necessary information in the query string. To facilitate this, some form of content must be requested using a standard HTML tag. The easiest way to do this without impacting the page itself is to load a 1x1 transparent gif. Note that in the case of the Google script (and others), this image isn't actually added to the page. It's merely loaded via a javascript statement
var img1 = new Image();
img1.src = 'http://path/to/file.gif?otherinfohere';
This loads the image without adding it to the page. The information could also be loaded using a script tag like so:
<script src="http://path/to/script.js?otherinfohere" type="text/javascript"><script>
However, users are more likely to have javascript blocked than images, so the safer route is to request an image. As to why they would use a gif instead of say, a jpg, a gif is safer in case a rogue browser actually adds the image to the page. The transparent gif is unlikely to negatively impact the layout, where as a 1x1 jpg would leave a 1 pixel dot somewhere on the page.
Edit: To add to my comment about users having blocked javascript, a gif request containing static information can be added inside a noscript tag to allow basic tracking even in the event that javascript is disabled. To my knowledge, GA doesn't do this, but some other web analytics providers do.
Even with JavaScript enabled, analytics requests a GIF file. If you look at the GET params of the image, it contains a lot of information about the browser. Stuff like utmsr=1280x1024 (the screen size). Google Code has a list of parameters.
It uses the image request to send information about the browser without an XMLHttpRequest.
Now, to actually answer the original question, Google is probably doing this to get around cross-domain XMLHttpRequest restrictions.
http://www.perlmonks.org/?node_id=7974
The smallest transparent GIF is 43 bytes.
http://garethrees.org/2007/11/14/pngcrush/
The smallest transparent PNG-24 (which can't be shown by older browsers too) is 67 bytes.
http://www.techsupportteam.org/forum/digital-imaging-photography/1892-worlds-smallest-valid-jpeg.html
The smallest (opaque) JPEG is 134 bytes.
The math is simple! Bigger size = more costs.
you can use the __utm.gif tracker without javascript (w some server help)
you can use it in an email message (w some programmatic help before sending the email)
Urchin was developed before AJAX was popular (2005)
It has nothing to do w cross-domain. They could have used JSONP for that.