Skip to content
Learn Measure Blog Case studies About
The PWA community is coming together for #PWASummit22. Have a great story about developing a web app? Submit your talk today
On this page
  • Q & A with Jake Archibald
    • Why the web?
    • What worked really well during development?
    • If you could have any API to improve your app, what would it be?
  • Home
  • All articles

SVGOMG

Mar 24, 2015 — Updated Mar 24, 2015
Paul Bakaus
Paul Bakaus
TwitterHomepage
On this page
  • Q & A with Jake Archibald
    • Why the web?
    • What worked really well during development?
    • If you could have any API to improve your app, what would it be?
Svgomg screenshot

TL;DR #

SVGOMG: A beautiful, material, responsive frontend for SVGO.

What we like? #

Built by our own Jake Archibald, SVGOMG is an almost perfect example of a fully responsive and capable tool written with web technologies. It features a beautiful Material Design look, ServiceWorker ensures that the app loads quickly and is available offline, and the transitions are smooth on mobile.

Possible Improvements #

The only real nitpick we'd have to offer is that the initial UX is confusing due to the main UI missing. Other than that, job well done!

Q & A with Jake Archibald #

Why the web? #

Laziness. Total laziness. I'm not an expert in developing Windows native apps, I'm not an expert in OSX native apps, nor am I an expert in creating native apps for iOS, Android, Windows Phone or Linux. I can however do the web, and that one skill set let me build something once that worked on all those platforms.

What worked really well during development? #

I'm really happy with the performance of it. I ensure the page renders before JS is available. In fact, it gets to first render with only 5k of HTML with some inlined CSS and SVG. The main scripts and CSS are all loaded in the background. This means the site appears to load in 1.5s even on 3G with an empty cache, and most of that is DNS and SSL.

The opening screen is really simple, so doing that in 5k wasn’t a challenge. It really bothers me that so many sites wait on JS for their first render, some even require their JS to make further requests before rendering. This pushes 3G render time towards 10s – as a mobile user I know I wouldn’t put up with that.

The main JS is 15k, but doesn’t include the parts that parse and minify the SVG, that’s loaded as an extra phase in the background. It’s great because interactivity lands really quickly, and the user doesn’t notice the extra loading. If the user manages to select an SVG before that script is available, the loading of that script appears to be part of the processing time.

I also used ServiceWorker to make the whole thing work offline. Working offline is a pretty cool feature, but I’m mostly doing it for performance. Subsequent visits to SVGOMG render almost instantly, whatever connection the user has. Given the variations in mobile connectivity, that’s really valuable!

If you could have any API to improve your app, what would it be? #

I used Babel so I could make use of future JavaScript stuff. It'd be great to have some of that working natively in the platform. Specifically, async/await, arrow functions, argument defaults and destructuring.

I had to use a library to gzip the output to find out its gzipped size. Using a library for this is kinda annoying as that code is already in the browser for HTTP stuff, there's just no API to it. Ideally it should be some kind of transform stream so I can count the size of the output without having the whole thing in memory.

Case Study
Last updated: Mar 24, 2015 — Improve article
Return to all articles
Share
subscribe

Contribute

  • File a bug
  • View source

Related content

  • developer.chrome.com
  • Chrome updates
  • Web Fundamentals
  • Case studies
  • Podcasts
  • Shows

Connect

  • Twitter
  • YouTube
  • Google Developers
  • Chrome
  • Firebase
  • Google Cloud Platform
  • All products
  • Terms & Privacy
  • Community Guidelines

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies.