如何在前端工程中在自动压缩图片

一、需求背景

在项目开发中,从设计师那里拿到图片后,不知道小伙伴们都是怎么处理的呢?
是不是都习惯了将图片扔到tinypng.com进行压缩后再放回到项目上提交?

由于设计师给的图片一般是原图,直接放到项目上,会因为大小过大,影响用户体验。所以开发在拿到图片后,一般会先进行压缩,牺牲一点品质,换取大小上的优化。

而每次手动压缩再上传的流程,效率着实不高,对一个程序员来说,不断做重复工作时,就要考虑是不是该换种操作了。

二、工具选择

像 tinypng.com 在线工具,背后使用了多种压缩方式,能极大程度地降低图片大小,压缩率很高。但同时也存在一些局限,比如只能压缩png和jpg、受网络线路影响、压缩接口有次数限制,需要付费解锁等。

而本地工具 imagemin,不仅没有网络限制,也不需要付费,通过插件体系,还可以加载不同的压缩工具处理各种情况。

经过简单的对比,选择了 imagemin 作为压缩工具。

三、压缩时机

在项目中的自动化操作,很自然就想到了 webpack。通过使用 webpack,在 build 的时候进行压缩。打包出来的图片就是压缩好的了,而且 webpack 中,各种插件也比较全,很容易就能找到合适的压缩插件。

但使用 webpack 有个问题,在每次构建时,都会执行压缩操作,而且压缩过的文件也会被再次执行压缩。图片多的情况下,压缩过程耗时也会相对更多。

那有没有在提交新文件前进行压缩的操作?

答案是 line-staged。
line-staged 一般用的比较多的地方是配合 eslint 进行提交前的格式校验和格式化,但其实它的作用远不止于此。它的作用很纯粹,就是再提交更改前,将更改文件的 path 作为参数传到配置的命令行工具上,也就是说,我们可以再这里配置压缩工具,就能够在提交图片前进行压缩。

四、命令行工具

line-staged 上推荐了一个图片压缩的工具:imagemin-lint-staged。但是其使用的是无损压缩,不能满足项目的需求。所以我参考 imagemin-lint-staged 自己写了一个:imagemin-linter。可进行有损压缩与无损压缩的配置,使用如下:

安装:

npm i -D husky lint-staged imagemin-linter

配置 package.json:

    ...
    "husky": {
        "hooks": {
            "pre-commit": "lint-staged"
        }
    },
    "lint-staged": {
        "*.{png,jpeg,jpg,gif,svg}": "imagemin-linter",
    },
    ...

配置完成后,在每次提交更改时,就能自动对图片进行压缩。

你可能感兴趣的:(如何在前端工程中在自动压缩图片)