❶ 前端性能优化--图片篇
有损压缩，高品质的压缩方式。图片体积压缩至原有体积的50%以下时，jpg仍然可以保持60%的品质。原理为以24位存储单个图，可以呈现多达1600万种颜色，足以满足大多数场景下对色彩的要求，这一点决定了它压缩前后的质量损耗并不容易被肉眼察觉。
优点：
缺点：
使用场景：
无损压缩，高保真的图片格式。同时支持8位和24位二进制的位数，八位的png最多指出256种颜色，24位可以呈现约1600万种。
优点：
缺点：
使用场景：
最多支持256种颜色的8位无损图片格式。
优点：
缺点：
使用场景：
同时提供了有损压缩和无损压缩（可逆压缩）的图片文件格式。像JPEG一样对细接丰富的图片信手拈来，像PNG一样支持透明，像GIF一样可以显示动态图片。
优点：
缺点：
在压缩文件大小的过程中，损失了一部分图片的信息，也降低了图片的质量，并且这种损失是不可逆的。常见的压缩手段是按照一定的算法将邻近的像素点进行合并，去除了人肉眼无法识别的图片细节。jpg图片使用的就是有损压缩。
在压缩的过程中，图片的质量没有任何损伤。任何时候都可以从无损压缩过的图片中恢复出原来的信息。压缩算法是对图片的所有的数据进行编码压缩，能在保证图片的质量的同时降低图片的体积。例如png、gif使用的就是无损压缩。
https://tinypng.com/
https://tu.isux.us/
https://compressor.io/
webpack配置imge-webpack-loader进行图片压缩
1.安装依赖
2.配置webpack
雪碧图，CSS Sprites，国内也叫 CSS 精灵，是一种 CSS 图像合成技术，主要用于小图片显示。
浏览器请求资源的时候，同源域名请求资源的时候有最大并发限制，chrome 为 6 个，就比如你的页面上有 10 个相同 CDN 域名小图片，那么需要发起 10 次请求去拉取，分两次并发。第一次并发请求回来后，发起第二次并发。如果你把 10 个小图片合并为一张大图片的画，那么只用一次请求即可拉取下来 10 个小图片的资源。减少服务器压力，减少并发，减少请求次数。
优点：
缺点：
有相应的插件提供了自动合成雪碧图的功能并且可以自动生成对应的样式文件webpack-spritesmith
将src/ico目录下的所有png文件合成雪碧图，并且输出到对应目录，同时还可以生成对应的样式文件，样式文件的语法会根据你配置的样式文件的后缀动态生成。
将图片转换为base64编码字符串inline到页面或css中。
优点：
缺点：
图片懒加载的原理就是暂时不设置图片的 src 属性，而是将图片的 url 隐藏起来，比如先写在 data-src 里面，等当前图片是否到了可视区域再将图片真实的 url 放进 src 属性里面，从而实现图片的延迟加载。
优点：
将图片提前加载到本地缓存中，从而提升用户体验。
高品质图像加载完之前会先显示低画质版本。低画质版本由于画质低、压缩率高、尺寸小、加载很快。
注：
很多工具和库都支持导出渐进式JPEG，比如 ImageMagick, libjpeg, jpegtran, jpeg-recompress以及imagemin。 也可以使用 gulp-imagemin 进行批量转换。
Photoshop导出渐进式图片，保存为JPEG格式，勾选连续。
❷ 2020-05-09 前端图片太多，图片太大怎么优化
1、小图多可以用图标，例如阿里巴巴iconfont库 https://www.iconfont.cn/home/index 。
2、使用精灵图。
3、大图可以进行压缩，压缩网站eg: https://tinypng.com/ 。
4、图片懒加载，像淘宝或者京东这样的APP页面上有很多图片,当我们滑到下一屏时下一屏的图片才会加载,这就采用了图片懒加载的方式.图片懒加载,简单来说就是在页面渲染过程中,图片不会一次性全部加载,会在需要的时候加载,比如当滚动条滚动到某一个位置时触发事件加载图片,通过js将img标签的data-src属性赋值给src属性。
5、使用webp格式，缺点：浏览器支持度不够
❸ 浅谈前端的图片优化
近期一直在和朋友讨论前端性能优化的问题，着重聊到了图片相关的优化，就想着总结记录一下。
说到图片优化主要从两个点入手，分别是优化体积和合并请求，下面我分别展开说下这两点。
就优化体积来说，方法还是比较有限，无外乎压缩图片大小，根据视图需要选择合适的图片尺寸。
我们知道图片是有很多格式的，包括jpg、png、gif等，单就大小来说有损压缩的jpg格式一般是会比无损压缩的png要小的多的，但是它不支持透明；且单就png来说还区分png8、png24、png32，我们需要根据自身业务使用场景选择最优的格式，当然如果支持webp的话webp一定是最优解。
选择尺寸就更好理解了，比如视图是一个固定400*300的区域，你肯定不需要放一个4000*3000的图片上去，当然现代的前端项目或多或少都需要考虑不同端的适配，我这边的处理方式是通过公司私有的图片服务器处理，你只需要上传一张原图，获取图片时根据需要带长宽参数即可获得相应大小的图片。
请求合并是前端优化的必要手段，不止是针对图片，这里我只列举针对图片优化的方案，当然每种方案都有他的弊端。
用雪碧图来合并多张小图片的方案已经有很多年了，它成本低兼容好，确实能解决不少问题，但是使用雪碧图同时会带来一些副作用需要我们解决。
首先就是内存问题，由于我们把多张图片合并成一张大图，所以渲染时每次都会加载整张雪碧图，这样对于内存的开销来说实际上是更大的，解决的办法就是尽量减少图片间的留白，以及控制一张雪碧图的内容不要太多。
还有就是缩放的问题，我们都知道background-size是针对整张图片的缩放，在移动端适配多尺寸时再使用固定的px定位就会出现偏差，一般这个时候我们都会使用百分比或者rem的方式来处理，不过在部分机型上还是会出现边缘的情况，一个朋友提出了transform的解决方案，不过笔者目前还没有验证。
toDataUrl的方案相比于雪碧图晚了些，它可以通过base64字符串来描述图片本身从而减少图片的请求；它所带来的问题是会增大体积页面本身文件大小，而且由于是内联字符串会导致图片无法缓存。
最后就是通过iconfont/svg/CSS等方式来模拟图片展示，这个方案可以算是是最通用的兼容最好的方案，但是也不是绝对的完美方案；就iconfont来说只能是纯色的，不能像图片那样颜色丰富，而svg和css或多或少都有一些兼容性问题。
我们在优化图片的时候还可以设置一些缓存策略以及根据业务场景使用一些懒加载的策略，因为这两条属于所有请求通用的方案，这里就不展开说了。最后说一句我们在进行前端优化时需要根据自身需要定制优化方案，切不可为了优化而盲目优化。
❹ JS图片懒加载——前端性能优化
意义
懒加载（LazyLoad） 是前端优化的一种有效方式，能极大的提升用户体验，图片加载是其重点，如果加载图片过多将大大增 http请求次数或大小 ，然而更多时候 用户并不会浏览到全部加载进来的图片 ，这种代价是非常不值得的，所以当用户 浏览到当前视口时再去加载相应的图片 无疑是两全其美的选择
原理：只有 img 标签中的 src 写入了图片的地址，加载页面时才会请求图片，所以使用懒加载时在 src 中并不写入任何地址，把图片的真实地址放到 data- (标签内部属性可存数据) 属性中，在 js 中绑定鼠标滚动事件，其回调中遍历所有图片并作出判断， 将出现在视口中的图片的 'data-' 属性保存的地址放到 'src' 中即可
实现
HTML：
❺ web前端开发图片放大了不清晰
web前端开发图片放大了不清晰，需要优化浏览器的缩放算法
在网页上通过CSS样式对图片进行缩放从而导致图片模糊，究其原因是因为浏览器的缩放算法和图片处理软件的不同导致的差异。
所以，要解决这个问题，就需要优化浏览器的缩放算法。CSS属性image，rendering正是为此而存在的。CSS 属性用于设置图像缩放算法。它适用于元素本身，适用于元素其他属性中的图像，也应用于子元素。
❻ Web前端新手如何做好性能优化
今天小编要跟大家分享的文章是关于Web前端新手如何做好性能优化?影响用户访问的最大部分是前端的页面。网站的划分一般为二：前端和后台。我们可以理解成后台是用来实现网站的功能的，比如：实现用户注册，用户能够为文章发表评论等等。而前端呢?其实应该是属于功能的表现。
而我们建设网站的目的是什么呢?不就是为了让目标人群来访问吗?所以我们可以理解成前端才是真正和用户接触的。
除了后台需要在性能上做优化外，其实前端的页面更需要在性能优化上下功夫，只有这样才能给我们的用户带来更好的用户体验。不仅仅如此，如果前端优化得好，他不仅可以为企业节约成本，他还能给用户带来更多的用户，因为增强的用户体验。说了这么多，那么我们应该如何对我们前端的页面进行性能优化呢?
前端性能优化的方法?
一、content方面
1，减少HTTP请求：合并文件、CSS精灵、inlineImage
2，减少DNS查询：DNS查询完成之前浏览器不能从这个主机下载任何任何文件。方法：DNS缓存、将资源分布到恰当数量的主机名，平衡并行下载和DNS查询
3，避免重定向：多余的中间访问
4，使Ajax可缓存
5，非必须组件延迟加载
6，未来所需组件预加载
7，减少DOM元素数量
8，将资源放到不同的域下：浏览器同时从一个域下载资源的数目有限，增加域可以提高并行下载量
9，减少iframe数量
10，不要404
二、Server方面
1，使用CDN
2，添加Expires或者Cache-Control响应头
3，对组件使用Gzip压缩
4，配置ETag
5，FlushBufferEarly
6，Ajax使用GET进行请求
7，避免空src的img标签
三、cookie方面
1，减小cookie大小
2，引入资源的域名不要包含cookie
四、CSS方面
1，将样式表放到页面顶部
2，不使用CSS表达式
3，使用不使用@import
4，不使用IE的Filter
五、JavaScript方面
1，将脚本放到页面底部
2，将javascript和css从外部引入
3，压缩javascript和css
4，删除不需要的脚本
5，减少DOM访问
6，合理设计事件监听器、
六、图片方面
1，优化图片：根据实际颜色需要选择色深、压缩
2，优化css精灵
3，不要在HTML中拉伸图片
4，保证favicon.ico小并且可缓存
七、移动方面
1，保证组件小于25k
2，
以上就是小编今天为大家分享的关于Web前端新手如何做好性能优化的文章，希望本篇文章能够对正在从事web前端工作的小伙伴们有所帮助。想要了解
更多web前端知识记得关注北大青鸟web培训官网。最后祝愿小伙伴们工作顺利！
❼ 常用的前端性能优化方法有哪些
常用的优化有两部分
第一：面向内容的优化
1. 减少 HTTP 请求
2. 减少 DNS 查找
3. 避免重定向
4. 使用 Ajax 缓存
5. 延迟载入组件
6. 预先载入组件
7. 减少 DOM 元素数量
8. 切分组件到多个域
9. 最小化 iframe 的数量
10. 不要出现http 404 错误
第二：面向 Server
1. 缩小 Cookie
2. 针对 Web 组件使用域名无关性的
❽ 前端性能优化-雪碧图及其实现
CSS Sprites 因其英文被称为 雪碧图 。
主要用于把一堆小图标整合在一张背景透明的大图上，通过设置对应的位置来显示不同的图片，目的是大幅减轻服务器对图片的请求数量，是前端性能优化的一种方式。
1、 减少网页的HTTP请求，提高页面性能
2、减少图片命名的困扰
1、需要计算每个图片的位置
2、后期维护困难
通过设置每个 <i></i> 对应的 background-position 来展现不同位置的图标。
其中第一个参数代表x轴控制左右，第二个参数代表y轴控制上下。
默认情况下为
当设置x为负数，相当于固定展现框不动，图片向左侧移动，展现的是相对右侧的内容。同理当y为负数，图片向上侧移动，展现的是相对下方的内容。
❾ 前端图片压缩优化工具conversion
image-conversion 是一个简单易用的 JS 图片转换工具，提供了多种 Image、Canvas、File 和 dataURL 之间的转换方法。
另外，image-conversion 可以指定大小来压缩图片。
1、将图像压缩到 200kb：
2、以 0.9 的质量压缩图像
image-conversion 提供了多种方法来实现 Image、Canvas、File 和 dataURL 之间的转换，如下：
1、imagetoCanvas(image[, config]) {Promise(Canvas)}
将图像对象转换为画布对象。
2、dataURLtoFile(dataURL[, type]) {Promise(Blob)}
将 dataURL 字符串转换为 File(Blob) 对象，相当于把画布的内容转换成blob，type可以设置最终图片的格式。
type的值可以为："image/png", "image/jpeg", "image/gif"
3、compress(file, config) {Promise(Blob)}
压缩文件（Blob）对象。
4、compressAccurately(file, config) {Promise(Blob)}
根据大小压缩文件（Blob）对象。
5、canvastoDataURL(canvas[, quality, type]) {Promise(string)}
将 Canvas 对象转换为 dataURL 字符串，该方法可以进行压缩。
6、canvastoFile(canvas[, quality, type]) {Promise(Blob)}
将 Canvas 对象转换为 Blob 对象，此方法可以进行压缩。
7、dataURLtoImage(dataURL) {Promise(Image)}
将 dataURL 字符串转换为图像对象。
8、downloadFile(file[, fileName])
下载图片到本地。
9、filetoDataURL(file) {Promise(string)}
将 File(Blob) 对象转换为 dataURL 字符串。
10、urltoBlob(url) {Promise(Blob)}
通过图像 url 加载所需的 Blob 对象。
11、urltoImage(url) {Promise(Image)}
通过图片 url 加载所需的 Image 对象。
觉得效果不错的请帮忙加个关注点个赞，经常分享前端实用开发技巧
❿ 前端性能优化之路——图片篇。
本人是一名前端开发者，在公司负责目前负责信息流服务，为五大手机厂商和各大App提供服务，每天的请求就是以亿计算，加上我们又做了SSP和DSP，就是类似于网络广告联盟，腾讯广点通这种。接触过的应该知道，所以前端优化一直是我头痛的问题，不仅要注重用户体验，同时要兼顾收益，有时候必须牺牲一些用户体验，但是作为一名有思想的前端，还是努力规避掉，希望能和从事相同业务的同学一起学习交流一下，话不多说，就来分享我的性能优化之路，有什么不对的知识点，麻烦大家指出批评。
yahoo军规把大部分的前端优化都提到了，而在js优化这一块如果有兴趣的额，推荐大家去看《 高性能javascript 》,书里讲的非常详细。 https://segmentfault.com/a/1190000008481413
Media Queries 调用高清背景图
通过 devicePixelRatio的值，就可以区分普通显示屏和高清屏，当devicePixelRatio值等于1时（也就是最小值），那么它普通显示屏，当devicePixelRatio值大于1(通常是1.5、2.0)，那么它就是高清显示屏。这时候我们可以让UI准备2套图片，甚至是3套图片，不同像素的图利用媒体查询结合 devicePixelRatio 可以区分普通显示屏和高清显示屏，并给出了如下CSS设计方案：
也可以用less或者sass
如果省时间通用性高，就像我们是服务端用nginx对图片进行处理，想要什么样尺寸的图片自己裁切,我们提供了按比例缩放和自定尺寸的裁切方法，地址后拼接字符串就行。
与其他图片格式相比，在肉眼无法分辨图片质量差异的情况下，WebP的空间占用是最小的，目前国内外各大互联网公司都已经开始应用这一图片格式。比如美团
想实现首先是判断，即识别单次访问的来源浏览器是否支持 webp 格式，其次是执行，如果该浏览器支持，则将原图替换为 webp 格式，并返回。如果不支持，则显示原格式图片。 http://caniuse.mojijs.com/Home/Html/item/key/webp/index.html
在识别阶段，我们有两种方法：
1. Server 处理
只要有请求，服务端就能拿到你的User-Agent信息，通过对浏览器进行分类，支持webp放在白名单里，不支持的则为黑名单。判断为白名单，则直接调用，返回webp格式图片；反之，则显示原图。这种方式的优点在于，只需定期维护白名单即可，逻辑简单；缺点则在于不可扩展、不可测试、UA判断会出现不准确的情况。
Server处理中的另一种方式是通过读取 JavaScript 种下的 cookie来实现判断。这种方式的优点是表现稳定，访问速度更快，切换无压力。但缺点是，页面静态化会导致用户切换浏览器时不能自主更新，图片服务失效。比如用户用支持webp的浏览器A请求页面，这时缓存的静态页面均使用webp图片，但当该用户使用不支持webp的浏览器B时，访问网页则会出现请求不到图片的报错。
Client 处理，是美团云为美团主站提供的处理方式。在这种处理方式中，浏览器端发送的beacon webp 请求后，通过检测其加载情况来判定 webp 支持情况，然后浏览器写一个cookie。之后通过读取浏览器cookie判断是否支持webp，就可以进行下一步替换操作了。
2.替换图片过程中也是有两种处理方式：
在 server 端处理的优点是对下游开发者透明，缺点是静态页面的缓存数量会翻倍。
替换方式如下：
在 client 端处理可以比较好地应对页面静态化的情况，主要针对懒加载（非首屏）的图片进行处理，直接通过修改懒加载器来实现。
对非懒加载的图片暂时没有特别好的办法。目前，可用替换路径的方式来处理。
Client 处理实际上效果也是不错的，美团页面里90%以上的图片都是懒加载的，基本上都可以满足需求。对于大多数用户来说，采用Client 处理实现webp转换是个不错的选择。
既然提到图片这一块，我有忍不住想扯写些题外的tracking Pixel（像素追踪），几乎所有网站都会做数据的采集，上报统计。特别是我们做SSP、DSP广告这块需要获取例如
数据永远说的是实话，数据证明一切可能。如facebook广告投放的跨境电商朋友都会使用facebook Pixel(像素追踪)以获得各环节的精准数据。这样追踪数据后，我们才能投放广告后销量上去了，哪个才是效果最好的，哪个效果不好，进而通过多个数据对比，对广告进行合理的调整优化。
国内搜狗、网络、360、新浪都是用这种 tracking Pixel 方法，实际就是利用1px 的图片，在图片地址后缀拼接你需要的信息参数，浏览器在请求任何资源的时候会发送当前系统的数据，比如浏览器信息，操作系统信息，作为http请求头送过去，他们就能统计了。
为什么不用js请求统计？
并不是所有的页面都支持JS的！NoJSStats的实现机制就是网站分析中点击流数据获取的方式之一——Web Beacons，即在页面中嵌入一个1像素的透明图片，当该页面被浏览时，图片就会被请求加载，于是在后端的服务器日志中就会记录该图片的请求日志，这样就可以获得日志记录。
例如网络：
本文引用@美团云 提供的webP方法，感谢。