0

I have a project in Angular1.x using a lot of SVG files.

I have no idea what to do to SVG files to prepare them for production.

I don't want my page to invoke 50 calls to different SVG files. So what are my options and which tools do I have to accomplish them?

I use npm scripts to build my project.

Jonathan Eunice
  • 9,710
  • 1
  • 31
  • 42
guy mograbi
  • 659
  • 8
  • 11
  • 1
    Aren't those SVG files going to be cached in the browser anyway, the first time someone surfs your page? This is sort of how browsers work anyway; if you have 50 graphics on the page, that's going to cost you 50 web calls. – Robert Harvey Nov 27 '16 at 19:10
  • @RobertHarvey, html files I can use html2js, and save yet another call to every templateUrl in the project. Some svg files can be transformed to font. I am sure there are stuff I can do with svg files that have to remain as svg. – guy mograbi Nov 27 '16 at 19:42
  • https://css-tricks.com/understanding-and-manually-improving-svg-optimization/ – Robert Harvey Nov 27 '16 at 19:43
  • @RobertHarvey - isn't this article for the person creating the SVGs? I just have to bundle everything for production and use it in the code. Are there no optimiziations on my side? I saw I can inline the svg, or create a sprite. some places suggest angular's ng-include.. I'm still trying to figure out which is the best way to go. – guy mograbi Nov 27 '16 at 20:25
  • To go... where, exactly? – Robert Harvey Nov 27 '16 at 20:26
  • @RobertHarvey to best prepare my project for production – guy mograbi Nov 27 '16 at 22:15
  • 2
    What "best" means for you? That's a question nobody here can answer. You know what "you don't want", but what about "what you want"? – Laiv Nov 28 '16 at 07:20
  • @Laiv Given enough parameters, there is a 'best' answer if you ask me (IMO). I just found out we will be using http2 - so using a sprite is probably not desired. I still don't know if I will need to resize the images or if they will be delivered in the desired size. Same for colors. – guy mograbi Nov 28 '16 at 09:46

1 Answers1

2

You handle SVG files the same way you'd handle other web assets:

  1. In your build process, optimize ("minify") the files so they do not needlessly consume extra space or bandwidth. Tools like svgo do this trick. And there are already easy integrations into many build chains, such as gulp.

  2. Store them, if possible, on a content delivery network so that clients requesting these files hit a large, scalable network and storage resource, not your server. There is a cost to this, but generally a much lower one that serving all those HTTP GET requests from your main web server. (This step is highly, highly, ever so highly recommended for all image and other static assets; it often leads to large improvements in site load latency and site scalability.)

  3. You can consider bundling them, either embedded within HTML files, or in a data file such as a JSON resource. There is, however, no "one size fits all" bundling strategy. It depends on the size of the files and how they are used. Embedding/bundling strategies are usually not a transparent, trivial step. Finally, if you minify and CDN-offload the assets, the need for bundling is generally much reduced. If you do decide bundling is the way to go, look to your existing production packaging system. Tools like webpack often support specific bundling options, such as data URIs.

  4. Finally, consider SVG bundling as a refinement, to be handled after other build-process and packaging issues are solved and sorted. Your site can run just fine with a lot of image requests, and there are easy ways to optimize image requests (e.g. CDN offloading). The issues surrounding the rest of the build pipeline IME dwarf the issues associated with SVG per se. Get your horse and buggy in operation before worrying about how neatly trimmed the buggy is.

Jonathan Eunice
  • 9,710
  • 1
  • 31
  • 42
  • 1
    +1 to CDN approach. It also helps with versioning assets. Plus no more repeated assets all across your projects – Laiv Nov 28 '16 at 07:30