Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Very large images are loaded upon mount #24

Closed
jdhartley opened this issue Jul 10, 2018 · 11 comments
Closed

Very large images are loaded upon mount #24

jdhartley opened this issue Jul 10, 2018 · 11 comments

Comments

@jdhartley
Copy link

Upon mounting a vue-tel-input component, ALL flag images are loaded, which adds up to 4.1 MB gzipped. This is way too much, even if we lazy load the images

image

It seems that the images in behdad/region-flags are large files and the dimensions are way bigger than the displayed size. There's an open issue to provide alternate sizes fonttools/region-flags#12 but doesn't really seem to have much activity or push behind it.

I would propose switching to a sprite solution, maybe like patw0929/react-intl-tel-input's sprite@2x.png(64.2kb) / sprite.scss

Is there any interest in an update to switch to a sprite? Any other ideas? I am interested in using this component but I cannot justify the 4.1 MB of images right now!

@iamstevendao
Copy link
Owner

@jdhartley thanks for the suggestion, we will have this in the next release very soon!

@jdhartley
Copy link
Author

Great to hear Steven! Please let me know if I can help in any way

@jdhartley
Copy link
Author

@iamstevendao Hey Steven! Any update on this ticket?

@iamstevendao
Copy link
Owner

iamstevendao commented Jul 25, 2018

@jdhartley Thanks for baring with me, v2.0.2 published along with the fix for this issue.
Demo: https://educationlink.github.io/vue-tel-input/

@iamstevendao
Copy link
Owner

Although it's still not the best solution, I used the same sprite as the react repo you commented. However, I pointed the image to the static URL link (you can find it at src/assets/sprite.css), which is not a good practice.
We might need to change it later, every contribution is always appreciated.

@jdhartley
Copy link
Author

jdhartley commented Jul 25, 2018

Fantastic! Thank you for this update. It has a huge impact on our app's performance.

Would love to chat through options on how we might be able to use our own CDN instead of serving off of GitHub. My fear with using that particular url is its linked to master, so if that image ever changes, people using old versions of the Sprite CSS will run into issues. It may be good to lock to a specific commit sha instead of master, or like in /dist/, add a sha to the filename.

Edit: example of link with commit sha: https://raw.githubusercontent.com/EducationLink/vue-tel-input/c3103c72a17350c2ba4d0d2ad6ff2c1e5727c58e/src/assets/flags.png

@ajmas
Copy link
Contributor

ajmas commented Aug 2, 2018

Would splitting up the flags into individual files help?

@iamstevendao
Copy link
Owner

@ajmas would you be able to give it a shot? As long as it won't increase the size of all flag images it needs to load.

@ajmas
Copy link
Contributor

ajmas commented Aug 4, 2018

@iamstevendao if I have a bit of time. My next few days aren’t going to allow me to look. I encourage anyone who has a bit of time to look too. Maybe compare what other telephone widgets are doing too, even if they are angular or react based?

@blord-fullscreen
Copy link

Would splitting up the flags into individual files help?

It would help performance if both:

  • the site is only specifying a subset of the available countries (possibly true in some cases).
  • the images are being requested from an HTTP/2.0 server that can multiplex lots of small files together efficiently in the response. Note that this is currently false for content served from raw.githubusercontent.com, which does not support HTTP/2.0.

In all other cases it will actually hurt perfomance, by ballooning the number of HTTP requests for the same content. This is why image spriting was invented in the first place.

A more flexible, possibly better solution would be a refactor allowing the developer to point to their own image resource(s), with the githubusercontent URL as a default. There could be a root path supplied as a prop, for example, and a toggle for whether the images are supplied as a sprite or as separate images.

Note that all of these refactors are breaking, which makes it all the more important to get the image URL in master to point to a specific commit SHA, as @jdhartley suggested. Otherwise updates will break things.

@ajmas
Copy link
Contributor

ajmas commented Aug 6, 2018

Maybe to allow the images URL to be a configurable option would be a first step? While it doesn’t solve the issue outright, it does allow for a short term solution, for anyone not wanting to point a CDN they don’t control.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants