3 ms·
Super neat, the end result looks great and adds a lot to the posts. On the downside, inlining the map causes the HTML to balloon up to ~500kB/~180kB gzipped, co
by lelandfe 2y ago
Super neat, the end result looks great and adds a lot to the posts. On the downside, inlining the map causes the HTML to balloon up to ~500kB/~180kB gzipped, compared to 30kB/10kB on this post (which lacks a map). The site is already insanely fast, but you could pull the map SVG into an actual file, so it's cached between pages, and becomes a lower-priority resource (which will ~halve First Contentful Paint). Then you'd just position the circle on top of that generic map file!
- gampleman 2y agoYou could then also run it through SVGO to compress it further.
- lelandfe 2y agoIndeed - looks like SVGO can crush that map from 500kB down to like 80kB! Users on constrained data plans will love that. Of course, the author notes they want higher fidelity at some point. They could consider breaking the SVG into quadrants, perhaps? Or something more clever :)
- ipsento606 2y agothe author is also using many large, multi-megabyte photos in their travel posts, so I'm not sure how significant the size of the SVG content is, in comparison
- lelandfe 2y agoBig inlined resources impact paint time - a lot! You'll see this by running Lighthouse/PageSpeed Insights on the posts. E.g. no map: https://imgur.com/a/5CJjEUq https://imgur.com/a/5CJjEUq vs map: https://imgur.com/a/mX1ZDz7 https://imgur.com/a/mX1ZDz7 That means users are staring at blank for longer. That can really stink on a poor connection. Images are requested at a lower priority and so don't cause the same problems for rendering. But it's a great idea to compress them, too, and use something like `srcset` to send an appropriately sized version!