Hacker News new | ask | show | jobs
by davidbyttow 3668 days ago
Thanks for the heads up guys!

We spent a good amount of time compressing our blocking bundle size (html, JS, CSS), which actually is JS for the entire app, not just that page. Certainly have more work to do, but given the amount of code, our JS/CSS is pretty low.

I just compressed the large image and it dropped to ~430KB.

Meanwhile, the other large asset is the animated GIF, which I suppose we could switch to a looping webm/mp4. Was hard to reduce the GIF further and keep the same quality...

Where's Pied Piper when you need them?
2 comments
oneeyedpigeon 3668 days ago
> We spent a good amount of time compressing our blocking bundle size (html, JS, CSS), which actually is JS for the entire app, not just that page

The problem with this approach is that, whilst it might be great for readers that view > n pages, the experience for viewing the first page is so terrible that many won't get past that one. It's still running at 37 requests, 2.7 MB, and 4.2 seconds even after your optimisations. Didn't load at all on my iPad.

If the javascript is for editing, it's clearly wasteful to deliver that to people who definitely won't be doing any editing; isn't it possible to defer that until it's needed?

link
noir_lord 3668 days ago
https://github.com/tjko/jpegoptim

https://github.com/Kjuly/pngcrush

You can use both from the cli as part of a build server/push to production.

jpegoptim in particular can make very good savings on lots of image types.

Example: http://i.imgur.com/Q4ggKXt.png

No appreciable loss in quality certainly for this use case.

link