5 ms·

This basic post with two images (four counting the logo and author avatar) clocks in at 30 requests and a plump 6.10 MB. Bold!

jdavis703 10y ago
I'm clocking in at 5.1MB which is still huge, but 4.4MB are from images alone. However their biggest image is a 2.8MB 24-bit monster PNG. That really could be a JPEG, with moderate compression it could come in at only a few hundred kilobyes I think.
- davidbyttow 10y 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?
  - oneeyedpigeon 10y 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?
  - noir_lord 10y ago
    https://github.com/tjko/jpegoptim https://github.com/tjko/jpegoptim https://github.com/Kjuly/pngcrush 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 http://i.imgur.com/Q4ggKXt.png No appreciable loss in quality certainly for this use case.
- thedaemon 10y ago
  I understand the large file size is a problem, but please don't suggest anyone use JPEG for images. It's a terrible format and I wish it would go away. It ruins artwork. I see the developer changed it to a JPEG and named it *.GIF. Weird, at any rate the problem is the large size of the image 2560x1600 @24. Even on my Surface Pro the image is far too large. Does anyone have a link the the original PNG? It would make a nice wallpaper. Also, anyone have credit for the artist?
  - jdavis703 10y ago
    JPEG doesn't ruin art any more than MP3 ruins music. I'd never send a compressed JPEG to a printer, just like I wouldn't send an MP3 to be mastered. But most users won't be able to tell the image quality difference if you fine tune the compression level, but they will notice a slow loading page.
    - thedaemon 10y ago
      As a pixel artist, I can say that: yes, JPEG does ruin art. I'm an artist, not a web developer so my perspective is different.
dingo_bat 10y ago
It's not even opening for me on mobile.
camillomiller 10y ago
It's also completely broken on mobile

jdavis703 10y ago

I'm clocking in at 5.1MB which is still huge, but 4.4MB are from images alone. However their biggest image is a 2.8MB 24-bit monster PNG. That really could be a JPEG, with moderate compression it could come in at only a few hundred kilobyes I think.

davidbyttow 10y 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?
- oneeyedpigeon 10y 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?
- noir_lord 10y ago
  https://github.com/tjko/jpegoptim https://github.com/tjko/jpegoptim https://github.com/Kjuly/pngcrush 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 http://i.imgur.com/Q4ggKXt.png No appreciable loss in quality certainly for this use case.
thedaemon 10y ago
I understand the large file size is a problem, but please don't suggest anyone use JPEG for images. It's a terrible format and I wish it would go away. It ruins artwork. I see the developer changed it to a JPEG and named it *.GIF. Weird, at any rate the problem is the large size of the image 2560x1600 @24. Even on my Surface Pro the image is far too large. Does anyone have a link the the original PNG? It would make a nice wallpaper. Also, anyone have credit for the artist?
- jdavis703 10y ago
  JPEG doesn't ruin art any more than MP3 ruins music. I'd never send a compressed JPEG to a printer, just like I wouldn't send an MP3 to be mastered. But most users won't be able to tell the image quality difference if you fine tune the compression level, but they will notice a slow loading page.
  - thedaemon 10y ago
    As a pixel artist, I can say that: yes, JPEG does ruin art. I'm an artist, not a web developer so my perspective is different.

dingo_bat 10y ago

It's not even opening for me on mobile.

camillomiller 10y ago

It's also completely broken on mobile