Optimización del rendimiento: compresión de imágenes, carga y selección de formato

Weihao.png

Este es el artículo original número 143 sin agua. Si desea obtener más artículos originales, busque en la cuenta oficial y síganos ~ Este artículo se publicó por primera vez en el blog front-end de Zhengcaiyun: Optimización del rendimiento: compresión, carga y formato de imágenes Selección

prefacio

Creo que todo el mundo ha oído hablar del " principio 258 ", el rendimiento de un sitio web afectará en gran medida la experiencia del usuario.

Después de haber experimentado varios proyectos de optimización del rendimiento del comercio electrónico y proyectos de pantalla grande, descubrí 图片资源que el procesamiento juega un papel fundamental en la optimización del rendimiento del sitio web.

Datos generales de solicitud del sitio web de comercio electrónico

Entre las solicitudes cargadas en la primera pantalla 145, las solicitudes de recursos de imagen representan 75%más, y las imágenes también representan una gran proporción de todas las solicitudes de recursos estáticos. Se puede ver la importancia de la optimización de la imagen.

Sin embargo, antes de entender la optimización de imágenes, primero comprendamos 二进制位数la 色彩呈现relación entre y.

Dígitos binarios y colores

En las computadoras, los píxeles generalmente se representan mediante números binarios. En diferentes formatos de imagen, la relación correspondiente entre píxeles y dígitos binarios es diferente. Cuantos más dígitos binarios correspondan a un píxel, más ricos serán los colores que puede representar, más refinado será el efecto de imagen y mayor será el espacio de almacenamiento necesario para la imagen.

En la actualidad existen en el mercado muchas formas de optimizar los recursos de imágenes, como comprimir imágenes, elegir el formato correcto, aceleración de CDN, carga diferida, etc.

Comprimir imagen

压缩图片Creo que es el primer plan en el que todo el mundo piensa. Al igual que el conocido tinpng , su principio es reducir la memoria que la imagen necesita almacenar reduciendo "selectivamente" la cantidad de colores que la imagen necesita almacenar.

When you upload a PNG (Portable Network Graphics) file, similar colors in your image are combined. This technique is called “quantization”. By reducing the number of colors, 24-bit PNG files can be converted to much smaller 8-bit indexed color images. 

下面我们来看下样例:

细节展示:

图片格式

压缩图片虽然在一定程度上可以减少我们请求的资源所需要的带宽,但如果是用对了格式在性能上往往会有质的改变。

JPEG/JPG

JPEG是最常用的图像文件格式。

优势

  • 支持极高的压缩率,可使文件传输、下载、预览速度大大加快。

  • 利用可变的压缩比可以控制文件大小。

  • 能够轻松地处理 1600 万种颜色,可以很好地再现全彩色的图像。

缺陷

JPG的有损压缩在轮播图背景图的展示上确实很难看出破绽,但当它处理矢量图形和 Logo 等线条感较强、颜色对比强烈的图像时,人为压缩导致的图片模糊会相当明显。因此不适宜用该格式来显示高清晰度线条感较强的图像。

除此之外,JPG并不支持对有透明度要求的图像进行显示,如果需要显示透明图片还是需要另寻它路。

业务场景

JPG适用于呈现色彩丰富的图片,在我们日常开发中,JPG 图片经常作为大的背景图轮播图 预览图出现。打开某电商网站首页,即可看到大图片的处理几乎都是使用了JPG

PNG-8 与 PNG-24 

png是一种采用无损压缩算法的位图格式。

优势

  • 无损压缩
  • 完全支持 alpha 透明度。
  • 可以重复保存且不降低图像质量。

缺点

体积太大

业务场景

理论上来说,当你追求最佳的显示效果(详情展示图、图片有放大需求、摄影作品等),并且不在意存储大小或所需带宽时,可以使用PNG-24。但实践当中,为了避免文件体积过大的问题,我们一般不用PNG去处理较复杂的图像。当我们遇到适合 PNG的场景时,也会优先选择更为小巧的 PNG-8

亦或者需要处理有透明度或线条明显的图片时,也会采用PNG。如网站主logo:

SVG

严格来说应该是一种开放标准的矢量图形语言。

优点

  • 可缩放,可支持无限放大
  • 可编程

缺点

  • 不是所有的浏览器都支持SVG,IE8和早期版本都需要一个插件。

  • 复杂的图片会降低渲染速度(只支持小图)。

业务场景

SVG 是文本文件,我们既可以像写代码一样定义 SVG,把它写在 HTML 里、成为 DOM 的一部分。用的比较多的就是iconfont。 我们可以通过设置模块的fill属性轻松适配图标的换肤功能,并通过font-size调节其大小。

Base64

一种基于64个可打印字符来表示二进制数据的方法。

优点

  • 减少网络请求
  • 对于动态实时生成的图片无需将图片存储在服务器占用服务器资源

缺点

  • 只适于小图。
  • 若需要频繁替换的图片需要整个代码替换,可维护性低。

业务场景

Base64雪碧图一样,是作为小图标解决方案而存在的。

Base64 是一种用于传输 8Bit 字节码的编码方式,通过对图片进行 Base64 编码,我们可以直接将编码结果写入 HTML 或者写入 CSS,从而减少 HTTP 请求的次数。

Elements中搜索“base64”关键字,你会发现 Base64也有很多使用的地方。而且它对应的图片占用内存较小。

既然Base64这么棒,我们把所有图片都用Base64好了嘛。

Base64编码后,图片大小会膨胀为原文件的4/3Base64编码原理)。如果我们把大图也编码到 HTML 或 CSS 文件中,后者的体积会明显增加,即便我们减少了 HTTP 请求,也无法弥补这庞大的体积带来的性能开销。也就是说我们牺牲的渲染性能大于资源请求性能,这样做不太值得。

我们可以看到,大多数用Base64编码的图片都是小图。

WebP

一种同时提供了有损压缩与无损压缩(可逆压缩)的图片文件格式。

优点

  • 支持有损无损

  • 占用体积小

  • 可支持透明

缺点

  • 兼容性不好

业务场景

JPEG/JPG。因为目前兼容性不好,一般搭配JPEG/JPG一起使用。

图片格式小结

给大家整理了思维导图:

OSS搭配CDN

我们原始的方式是将图片等资源一起放入项目中打包上线。

这样做的缺点在于打包出来的包大不说,用户请求资源的速度也会受到限制。比如我们的服务器在华南,华北的用户请求就会稍慢。当遇到并发量大的情况时,从部署服务器请求接口与资源这无外乎给我们的服务器提供了多余的压力。当我们临时想替换一张图片时,也需要重新打包并发布上线,非常麻烦。

当我们将图片进行OSS放置并CDN加速后,这个问题就得到了很好的解决。不同地区的用户可以访问就近服务器,重复的请求也会产生缓存,避免OSS流量的浪费。

《OSS和CDN的区别》大家也可以参考这篇文章进行细看。

图片的懒加载

相信大家一定会遇到首屏数据过多加载缓慢的情况。在这个情况下我们就需要考虑懒加载了。当用户滚动到预览位置时,在进行图片数据的请求。期间用骨架屏或缩略图代替。

window.onload = function () {
    // 获取图片列表,即img标签列表
    var imgs = document.querySelectorAll('img');
    // 获取到浏览器顶部的距离
    function getTop(e) {
        return e.offsetTop;
    }
    // 懒加载实现
    function lazyload(imgs) {
        // 可视区域高度
        var h = window.innerHeight;
        // 滚动区域高度
        var s = document.documentElement.scrollTop || document.body.scrollTop;
        for (var i = 0; i < imgs.length; i++) {
            //图片距离顶部的距离大于可视区域和滚动区域之和时懒加载
            if ((h + s) > getTop(imgs[i])) {
                // 真实情况是页面开始有2秒空白,所以使用setTimeout定时2s
                (function (i) {
                    setTimeout(function () {
                        // 不加立即执行函数i会等于9
                        // 隐形加载图片或其他资源,
                        // 创建一个临时图片,这个图片在内存中不会到页面上去。实现隐形加载
                        var temp = new Image();
                        temp.src = imgs[i].getAttribute('data-src');//只会请求一次
                        // onload判断图片加载完毕,真是图片加载完毕,再赋值给dom节点
                        temp.onload = function () {
                            // 获取自定义属性data-src,用真图片替换假图片
                            imgs[i].src = imgs[i].getAttribute('data-src')
                        }
                    }, 2000)
                })(i)
            }
        }
    }
    lazyload(imgs);
    // 滚屏函数
    window.onscroll = function () {
        lazyload(imgs);
    }
}
复制代码

尾声

性能优化是我们前端开发工程师必须要掌握的一门硬技能。和学习其他新技术不同的是,当你想学习一套新的框架时,阅读文档和源码几乎可以让你在使用过程中游刃有余。但性能优化却不一样,它只能让我们去摸索去领悟去突破,它是一种经验也是一种习惯更是一种嗅觉。

参考资料

最佳实践:使用阿里云CDN加速OSS访问

掘金小册: 前端性能优化原理与实践

壁纸网站: wellhaven

推荐阅读

如何基于 WebComponents 封装 UI 组件库

Web Worker

如何落地一个智能机器人

一名练习时长 2 年零 8 个月的前端练习生自述

浅析 Snabbdom 中 vnode 和 diff 算法

开源作品

  • 政采云前端小报

开源地址 www.zoo.team/openweekly/ (小报官网首页有微信交流群)

  • 商品选择 sku 插件

开源地址 github.com/zcy-inc/sku…

招贤纳士

政采云前端团队(ZooTeam),一个年轻富有激情和创造力的前端团队,隶属于政采云产品研发部,Base 在风景如画的杭州。团队现有 60 余个前端小伙伴,平均年龄 27 岁,近 4 成是全栈工程师,妥妥的青年风暴团。成员构成既有来自于阿里、网易的“老”兵,也有浙大、中科大、杭电等校的应届新人。团队在日常的业务对接之外,还在物料体系、工程平台、搭建平台、性能体验、云端应用、数据分析及可视化等方向进行技术探索和实战,推动并落地了一系列的内部技术产品,持续探索前端技术体系的新边界。

Si quieres cambiar, te han tirado con cosas y esperas empezar a tirar cosas; si quieres cambiar, te han dicho que necesitas más ideas, pero no puedes romper el juego; si quieres cambiar , tienes la capacidad de lograr ese resultado, pero no te necesitas; si quieres cambiar lo que quieres lograr, necesitas un equipo que te apoye, pero no hay lugar para que guíes a la gente; si Si quieres cambiar el ritmo establecido, será "5 años de tiempo de trabajo y 3 años de experiencia laboral"; si quieres cambiar el original La comprensión es buena, pero siempre está el desenfoque de esa capa de papel de ventana. Si crees en el poder de la creencia, cree que la gente común puede lograr cosas extraordinarias y cree que pueden encontrarse con un yo mejor. Si desea participar en el proceso de despegue con el negocio y promover personalmente el crecimiento de un equipo de front-end con un conocimiento profundo del negocio, un sistema técnico sólido, tecnología que crea valor e influencia indirecta, creo que deberíamos hablar. En cualquier momento, esperando que escribas algo, envíalo a[email protected]

Supongo que te gusta

Origin juejin.im/post/7098854314365419533
Recomendado
Clasificación