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
Related
Hei!
I have a quiz app that shows a list of active games. This list also shows the opponents profile image. The list is a stream from firestore.
Everytime the user changes to another screen and back to the gamelist the images are downloaded again..this uses alot of network traffic.
I cant put the images in cache when the app starts as i dont know what games the player have, and they are changing. Is there a way to get the image from url , put it in cache, and IF its in cache , use that image..in the same widget?
I believe cached_network_image package is what you need.
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 tried searching my specific problem but I could not find any suitable solution.
I would like to thank everybody in advance for your help.
I am currently developing an iOS app.
The App represents a user profile which can be updated by the user.
Everything from the authentication, registration and the possibility to update your user data works fine with the help of Firebase. Now I would like to optimize some code.
So the application has 2 Screens, HomeScreen and EditScreen.
(Besides the Screens needed for registration and login).
To keep my question short:
How can I reduce the amount of data which is loaded from firebase?
Example:
1. User is on the HomeScreen, to build the view his image loads from Firebase Storage
2. He wants to edit his Image and therefore switches to the Editscreen, where his image will be loaded again
3. After changing his image, the new image will be uploaded to Firebase Storage and he can see his new image on the Editscreen
4. If he now switches back to the HomeScreen his new image will be loaded again from Firebase
Is there a good way to reduce the amount of loading?
Like caching the image between step 1 and 2?
As there is always a little delay in displaying his image.
Thanks!
Sadly I am not allowed to share any code.
You can check out the flutter_advanced_networkimage package. It will cache your photo upon load. For everything else, you should just move your profile object (or whatever it is that calls for the firebase user's information) above those routes and pass it down through your widget tree through arguments or state management.
I'm currently building a single-page backbone app that embeds up to 10 separate Soundcloud iFrames on a single page. Users can then view other pages, each of which contain their own set of iFrames.
I've noticed that each time a new set of iframes is loaded the memory consumption for the tab increases roughly 80-100MB (according to the Chrome Task Manager). This memory is never relinquished, so after a few clicks the tab easily reaches 300MB and becomes intolerably slow. This slowness occurs in both Chrome 20 and Firefox 13.
After each page change I've tried .remove()'ing all the iframes as well as clearing out the container element via .html('') and neither stems the memory growth.
Provided in this gist is sample code that exhibits the same behavior as described above. On each load the individual iFrame consumes roughly 10MB of additional memory.
https://gist.github.com/3202151
Is the Soundcloud embed code doing something to maintain a handle to the iframe and preventing it from being GC'd? Is there another way I can remove the elements from the DOM to avoid the memory bloat?
Note: I cannot add all the tracks to a single set which can be loaded once since tracks being embedded are not my own.
I have been running into a similar problem. I'm using the SoundCloud js sdk to stream audio in a custom player on my site. I got it running and let it go all night (because I was suspicious of the swf size). Sure enough, in the morning the swf was massive and my computer was noticeably slow. The SoundCloud sdk uses SoundManager2 to stream/play audio, so it creates a soundManager object which you can access in JS. I ended up managing the swf size by calling
soundManager.reboot();
...between each song that plays. In your case you could call it between the various pages, keeping the memory to the 80-100MB max at a time. It increases the load time by a fraction of a second, but that's a small price to pay for fixing the ever-growing memory issue.
I'm not sure if the iframe player also creates the soundManager object, but if so, give this a try!
Check out the SoundManager2 documentation here:
http://www.schillmania.com/projects/soundmanager2/doc/#soundmanager-reboot
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.