# 图片仍然太大——如何进一步压缩？

**URL:** <https://meta.discourse.org/t/images-are-still-too-big-how-to-compress-further/50836>\
**Category:** Product Support\
**Created:** [2016 年9 月 28 日 23:36 UTC](https://meta.discourse.org/t/images-are-still-too-big-how-to-compress-further/50836 "2016-09-28T23:36:52Z")\
**Posts on this page:** 1\
**Showing post:** 11

<div class="post-metadata">

作者： ![codinghorror](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/codinghorror/32/110067_2.png) [@codinghorror](https://meta.discourse.org/u/codinghorror)\
发布日期： [2017 年5 月 22 日 21:59 UTC](https://meta.discourse.org/t/images-are-still-too-big-how-to-compress-further/50836/11 "2017-05-22T21:59:58Z")

</div>

The paint point here was very large uploaded PNGs which had absolutely no business being lossless PNGs, when they could be lossy JPGs at 1/5 or less the size. For small images (1280x720 or less) it does not matter so much, but get to 1080p++ and the cost becomes .. extreme.

```
1,651,936 Screenshot_2017-04-16-21-23-50.png
1,701,243 Screenshot_2017-04-16-21-23-54.png

  323,789 Screenshot_2017-04-16-21-23-50.jpg
  288,995 Screenshot_2017-04-16-21-23-54.jpg

```

This also has super bad ramifications for PNG optimizers which take n2 or worse time as the image gets larger.. here’s `pngout.exe` behavior by image size:

```
960x540
s1 → 2.1s
s2 → 2.2s

1280x720 (720p)
s1 → 3.7s
s2 → 3.2s

1920x1080 (1080p)
s1 → 32s
s2 → 33s

3840x2160 (4k)
s1 → 57s
s2 → 42s

```

---

_[View the full topic](https://meta.discourse.org/t/images-are-still-too-big-how-to-compress-further/50836)._