Ionic: fast loading images - angularjs

I am building a small app with Ionic 3 and angular 2/4
I have a problem to load a list of images from an URL (5MB per image)
It takes a lot of time to display my images.
How can I load images faster ?
There is any way to display images in low quality first ? (like Facebook and Whatsapp)
Any link, any tutorial, any blog ...
//js
private photo = "http://my-url.com";
private photo2 = "http://my-url-2.com";
//html
<div> <img [src]="photo"> </div>
<div> <img [src]="photo2"> </div>
Thank you !

The most convenient ways imho are:
compression - the first thing you need to ask yourself: Do I really need a 5mb image? Is it too big? Can it be compressed (e.g. jpeg/png)?
thumbnails - 1 (or more) version of the original image which are a lot smaller and therefore a lot faster to load. In many cases (e.g. list, overview) you don't even need the original image because the size of your img container is way smaller. So one way is to only load + display the size you need for that specific usecase. When you really need the 5mb version you could start with the thumbnail and replace it when the fullsize one is finished loading. This doesn't reduce the loading time, but feels way smoother.
preloading - you could preload the images (e.g. when you know they will be shown soon) to remove the slow loading part when your image is actually displayed.
caching - when your images don't change that much you might consider caching the images on your device. That way whenever you need to load a 5mb image for the second time (even after app restart) it takes the local copy instead of the remote one and can be shown almost instantly.
Ideally (and depending on your usecase) you combine all four things: Compressed images, different sized versions of your images, preloading when necessary and caching to make sure an image is only loaded once.
In my apps I'm using the simple but great plugin ionic-image-loader which I can highly recommend. It's easy to implement and covers 3. and 4. with almost no effort.
I hope I could help!

Related

How to make images resize as per client device size

I have a react app that has many image references ( tags <img src=... /> and css background:url(...)) type.
These images are hosted on Azure Storage.
To speed up my App loading time on various devices (desktops and mobile), I need to resize these images before they hit the client, ie, on the server somewhere.
So far, I can think of the following options:
Pick each image, and produce multiple versions of them for various standard device sizes. Then, pick up each <img src=... /> tag, and, using JS alter the image name, such that the right size of image gets served. This will not work with css.
Use Azure CDN to automatically resize images. I was hoping that resizing would happen automatically, as the CDN portal retrieves the user-agent from the device. Does anyone know if this is true?
Serve images through an Azure function, resizing them on the fly (as suggested here)
Can someone suggest other options they can think of, or a pros / con of the above.
Since you're using javascript, use the window tag. For browsers, the window tab measures the resolution of the browser and you can set the height and width of your image to window.innerHeight and window.innerWidth. There are multiple other ways to do this but this is the easiest and most optimised if your coding project needs to be efficient with the least lines of code necessary.
More info about the window object here : https://www.w3schools.com/js/js_window.asp
P.S. this is only a solution for desktop, for mobile you can use screen.width, screen.height. This might not work on desktop but on a macOS Big Sur device it works, I tried it (This might be because macOS Big Sur is like a mobile optimised interface given that you can even run iOS apps on it but we don't know unless we try). That might be a better option as it is most likely common across all your devices.
More info about the screen object here : https://www.tutorialrepublic.com/faq/how-to-detect-screen-resolution-with-javascript.php
On the off-chance that none of them are common across all of your target devices, try making a detector program with which you can detect the device type and store that in a variable. Then create 2 if statements saying
if(deviceType = iOS){
<img src=..., screen.width, screen.height/>
}else if(deviceType = Windows){
<img src=..., window.innerWidth, window.innerHeight/>
}
Obviously this code won't work but it's just there to show you the flow where you can sort of understand what I meant. You need to integrate it your own way but this was just a way to make it easier as many times people mention that my answers are not easy to understand, just as a safety measure.
The best part of these options is that instead of remade copies of the image itself, this will resize the one, which saves storage space and eliminates the chance of the user using an unexpected display output like a 49" Samsung Odyssey G9 monitor where the resolution is extremely far from what you might have expected and resized. This also means you don't have to create a separate file just to make image resizing code, just the one to detect the OS (not necessary if the screen object works) which would've already been done since this is Azure we're talking about and they always detect their user base.
If you have any queries, please reply back.
Good luck!

PWA advice needed regarding large number of static assets

I am a building a educational app that has around 1100 SVGs. They very small per svg like 800bytes. I am quite new to reactjs.
For each SVG I have an audio.
Therefore
1100 svgs
1100 audio clips
I am using create-react-app.
Intend using howlerJS to ensure audio files are cached.
Also lazy load the svgs.
Does create-react-app cache the svgs?
Should I change my approach? Maybe merge svgs into a sprite..
Should I merge mp3s and play parts of the audio as needed..
My main thing is that audio and svgs get installed when user installs PWA.
Any feedback will be appreciated
There is no magic bullet to your problem, but here are some key points to consider:
It won't take long for you to make a request and get a response for each and every pair of svg/audio that user selects (on demand, not 1100 altogether).
Not knowing your app's logic and UX, I can extrapolate that loading 3MB of SVG and 10MB of audio will be more noticeable, than waiting for on-demand request/response of 11KB.
As a background job, try to load as many files to upfront as you can, while there are no running requests from user.
Cache everything that was already loaded to avoid repeated requests
Try to optimize your sources in the first place, since minimal changes to an individual file will lead to a major impact on scale of x1000. A good place to start is checking your floating point in SVG: try to avoid something like <path d="M33.6286316,13.9605932... and keep it as simple as your precision allows you to. In most cases <path d="M33.62,13.96... will do the job.

Best strategy for a magazine app

I'm developing a Magazine app and trying to find the best strategy to optimize performance and stability. The app should be able to handle +100 pages and expect users to swipe between them fast and smoothly.
With all this in mind, this is what I've tried so far.
The basic structure would be using tabs, with tabs bar hidden, to allow user swipe. Since loading + 100 tabs with huge images would be a mistake, I always mantain three tabs: the current page, the previous and the following. With a selection listener I change the positions accordingly.
The way I load and dispose images as selection changes is the big deal here. The app downloads the images from Internet and cache them in FileSystemStorage. Those images are 768 x 1024. This is what I've tried with different luck:
Simply retrieve the images from FileSystem everytime a new page is requested:
if (FileSystemStorage.getInstance().exists(rutaImagen)) {
try {
int size = (int) FileSystemStorage.getInstance().getLength(rutaImagen);
EncodedImage imagenPubli = EncodedImage.create(FileSystemStorage.getInstance().openInputStream(rutaImagen), size);
} catch(IOException io) {
}
}
This has proven to be inefficient and risky in terms of memory usage. My iPad mini launch frequent low memory warnings, and end up killed by jetsam after a little while.
Store the images in a WeakHashMap, so Images don't need to be constantly loaded form FileSystemStorage, which seems to be the cause of problems and too expensive. Only if they are garbage collected, the first method comes in action.
This solution perfoms better, and the memory warnings are dramatically reduced, but are still there. After stressing hard the app, 15 or 20 minutes later jetsam jumps in and kill the app.
Similar approach: instead of WeakHashMap, I have tried CacheMap. This has been the best solution for me so far. I have to push hard to see some memory warnings once in a while, and no crash so far. Still not enterily happy though, because I believe I should not see any memory warnings at all.
I talk about iOS only here because the app performs well on Android whatever method I use, and I have never got any Out of Memory there.
What do you think? Am I in the right path? Would you guys use a different approach?
Thanks
I believe that you should use the "let-it-be-done" approach. So far you have tried to code everything yourself, while codenameOne has many optimized way of doing it. The easiest way would be to use a MultiList, which will display your images (by using an UrlImage). The UrlImage will allow codenameone to handle the caching and else. Basically, the image will be loaded when viewed and placed in cache afterwards.
It's unclear from the question where the magazine page is just an image. If so I would suggest using the ImageViewer class as it was designed exactly with the use case of an infinite list of large images to swipe and zoom thru.
The general strategy with the Tabs seems like a good start if you need something more elaborate than images. If it doesn't perform well you can always substitute Tabs for something else.

Is there anyway to improve the Javascript Built Apps's web page loading time?

I found the first web page loading time for CN1 Javascript Built taking too long, need about 2 minutes.
I attached the Chrome's network loading screen shot, found the classes.js is the most heavy page, possible to zip it?
Second, there is 2 theme files that downloaded sequentially, is it possible for them to load at the same time?
Kindly advice.
Normally I would answer that you can look at the performance section of the developer guide but the relevant sections there relate to reducing the theme.res size which seems pretty small in your case.
The largest portion in your code is the class files so I'm guessing that the best way to reduce them is to further reduce dependencies so the obfucator can remove more dead code. Keep in mind that the classes.js file is cached and can be deployed via CDN's such as cloudflair to improve download speeds. It can be served in a gzipped form as well which is a part of the CDN repertoire.

Optimizing a slideshow and an image gallery [GAE / GWT]?

I would like to implement my own slideshow and image gallery (for a foto reporting website).
Is there a best approach or tehcniques (using GAE and GWT) related to :
reducing the slideshow's loading time (a slideshow containing 30 images (960px * 780px) for example, should I load them all firstly and then let the user navigating ?)
should I do scaling operation (the image's resolution is greater than the browser's one) on the server side or in the client side ?
is there some know-well problem concerning the storage (if I have a lot of images) ?
If you have some advice or links about this topics, could you post them please ? Thanks you.
Question 1: preload vs lazy
Answer: The more you load to start the longer it takes your instance to spin up and the longer and larger the bandwidth. So in general you should probably use a lazy loader but prefetch the thumbnails and the next image.
Question 2: image scaling
Answer: I suggest creating a scaled version on upload that you serve then allow the user to download the full size image. Don't do this on the client again the bandwidth would eat you alive.
Question 3: storage
Answer: Use the blobstore/python or blobstore/java instead of db.BlobProperty because it saves money on storage and allows for files over 1mb.

Resources