monkeykg

monkeykg 查看完整档案

杭州编辑河南科技大学  |  自动化 编辑浙江房喜喜  |  前端开发 编辑填写个人主网站
编辑

打怪练级

个人动态

monkeykg 关注了用户 · 2020-08-05

政采云前端团队 @zhengcaiyunqianduantuandui

Z 是政采云拼音首字母,oo 是无穷的符号,结合 Zoo 有生物圈的含义。寄望我们的前端 ZooTeam 团队,不论是人才梯队,还是技术体系,都能各面兼备,成长为一个生态,卓越且持续卓越。

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

关注 2632

monkeykg 收藏了文章 · 2019-08-31

不要再问我跨域的问题了

写下这篇文章后我想,要不以后就把这种基础的常见知识都归到这个“不要再问我XX的问题”,形成一系列内容,希望大家看完之后再有人问你这些问题,你心里会窃喜:“嘿嘿,是时候展现真正的技术了!”
一、不要再问我this的指向问题了

跨域这两个字就像一块狗皮膏药一样黏在每一个前端开发者身上,无论你在工作上或者面试中无可避免会遇到这个问题。为了应付面试,我每次都随便背几个方案,也不知道为什么要这样干,反正面完就可以扔了,我想工作上也不会用到那么多乱七八糟的方案。到了真正工作,开发环境有webpack-dev-server搞定,上线了服务端的大佬们也会配好,配了什么我不管,反正不会跨域就是了。日子也就这么混过去了,终于有一天,我觉得不能再继续这样混下去了,我一定要彻底搞懂这个东西!于是就有了这篇文章。

要掌握跨域,首先要知道为什么会有跨域这个问题出现

确实,我们这种搬砖工人就是为了混口饭吃嘛,好好的调个接口告诉我跨域了,这种阻碍我们轻松搬砖的事情真恶心!为什么会跨域?是谁在搞事情?为了找到这个问题的始作俑者,请点击浏览器的同源策略
这么官方的东西真难懂,没关系,至少你知道了,因为浏览器的同源策略导致了跨域,就是浏览器在搞事情。
所以,浏览器为什么要搞事情?就是不想给好日子我们过?对于这样的质问,浏览器甩锅道:“同源策略限制了从同一个源加载的文档或脚本如何与来自另一个源的资源进行交互。这是一个用于隔离潜在恶意文件的重要安全机制。”
这么官方的话术真难懂,没关系,至少你知道了,似乎这是个安全机制。
所以,究竟为什么需要这样的安全机制?这样的安全机制解决了什么问题?别急,让我们继续研究下去。

没有同源策略限制的两大危险场景

据我了解,浏览器是从两个方面去做这个同源策略的,一是针对接口的请求,二是针对Dom的查询。试想一下没有这样的限制上述两种动作有什么危险。

没有同源策略限制的接口请求

有一个小小的东西叫cookie大家应该知道,一般用来处理登录等场景,目的是让服务端知道谁发出的这次请求。如果你请求了接口进行登录,服务端验证通过后会在响应头加入Set-Cookie字段,然后下次再发请求的时候,浏览器会自动将cookie附加在HTTP请求的头字段Cookie中,服务端就能知道这个用户已经登录过了。知道这个之后,我们来看场景:
1.你准备去清空你的购物车,于是打开了买买买网站www.maimaimai.com,然后登录成功,一看,购物车东西这么少,不行,还得买多点。
2.你在看有什么东西买的过程中,你的好基友发给你一个链接www.nidongde.com,一脸yin笑地跟你说:“你懂的”,你毫不犹豫打开了。
3.你饶有兴致地浏览着www.nidongde.com,谁知这个网站暗地里做了些不可描述的事情!由于没有同源策略的限制,它向www.maimaimai.com发起了请求!聪明的你一定想到上面的话“服务端验证通过后会在响应头加入Set-Cookie字段,然后下次再发请求的时候,浏览器会自动将cookie附加在HTTP请求的头字段Cookie中”,这样一来,这个不法网站就相当于登录了你的账号,可以为所欲为了!如果这不是一个买买买账号,而是你的银行账号,那……
这就是传说中的CSRF攻击浅谈CSRF攻击方式
看了这波CSRF攻击我在想,即使有了同源策略限制,但cookie是明文的,还不是一样能拿下来。于是我看了一些cookie相关的文章聊一聊 cookieCookie/Session的机制与安全,知道了服务端可以设置httpOnly,使得前端无法操作cookie,如果没有这样的设置,像XSS攻击就可以去获取到cookieWeb安全测试之XSS;设置secure,则保证在https的加密通信中传输以防截获。

没有同源策略限制的Dom查询

1.有一天你刚睡醒,收到一封邮件,说是你的银行账号有风险,赶紧点进www.yinghang.com改密码。你吓尿了,赶紧点进去,还是熟悉的银行登录界面,你果断输入你的账号密码,登录进去看看钱有没有少了。
2.睡眼朦胧的你没看清楚,平时访问的银行网站是www.yinhang.com,而现在访问的是www.yinghang.com,这个钓鱼网站做了什么呢?

// HTML
<iframe name="yinhang" data-original="www.yinhang.com"></iframe>
// JS
// 由于没有同源策略的限制,钓鱼网站可以直接拿到别的网站的Dom
const iframe = window.frames['yinhang']
const node = iframe.document.getElementById('你输入账号密码的Input')
console.log(`拿到了这个${node},我还拿不到你刚刚输入的账号密码吗`)

由此我们知道,同源策略确实能规避一些危险,不是说有了同源策略就安全,只是说同源策略是一种浏览器最基本的安全机制,毕竟能提高一点攻击的成本。其实没有刺不穿的盾,只是攻击的成本和攻击成功后获得的利益成不成正比。

跨域正确的打开方式

经过对同源策略的了解,我们应该要消除对浏览器的误解,同源策略是浏览器做的一件好事,是用来防御来自邪门歪道的攻击,但总不能为了不让坏人进门而把全部人都拒之门外吧。没错,我们这种正人君子只要打开方式正确,就应该可以跨域。
下面将一个个演示正确打开方式,但在此之前,有些准备工作要做。为了本地演示跨域,我们需要:
1.随便跑起一份前端代码(以下前端是随便跑起来的vue),地址是http://localhost:9099。
2.随便跑起一份后端代码(以下后端是随便跑起来的node koa2),地址是http://localhost:9971。

同源策略限制下接口请求的正确打开方式

1.JSONP
在HTML标签里,一些标签比如script、img这样的获取资源的标签是没有跨域限制的,利用这一点,我们可以这样干:

后端写个小接口

// 处理成功失败返回格式的工具
const {successBody} = require('../utli')
class CrossDomain {
  static async jsonp (ctx) {
    // 前端传过来的参数
    const query = ctx.request.query
    // 设置一个cookies
    ctx.cookies.set('tokenId', '1')
    // query.cb是前后端约定的方法名字,其实就是后端返回一个直接执行的方法给前端,由于前端是用script标签发起的请求,所以返回了这个方法后相当于立马执行,并且把要返回的数据放在方法的参数里。
    ctx.body = `${query.cb}(${JSON.stringify(successBody({msg: query.msg}, 'success'))})`
  }
}
module.exports = CrossDomain

简单版前端

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8">
  </head>
  <body>
    <script type='text/javascript'>
      // 后端返回直接执行的方法,相当于执行这个方法,由于后端把返回的数据放在方法的参数里,所以这里能拿到res。
      window.jsonpCb = function (res) {
        console.log(res)
      }
    </script>
    <script data-original='http://localhost:9871/api/jsonp?msg=helloJsonp&cb=jsonpCb' type='text/javascript'></script>
  </body>
</html>

简单封装一下前端这个套路

/**
 * JSONP请求工具
 * @param url 请求的地址
 * @param data 请求的参数
 * @returns {Promise<any>}
 */
const request = ({url, data}) => {
  return new Promise((resolve, reject) => {
    // 处理传参成xx=yy&aa=bb的形式
    const handleData = (data) => {
      const keys = Object.keys(data)
      const keysLen = keys.length
      return keys.reduce((pre, cur, index) => {
        const value = data[cur]
        const flag = index !== keysLen - 1 ? '&' : ''
        return `${pre}${cur}=${value}${flag}`
      }, '')
    }
    // 动态创建script标签
    const script = document.createElement('script')
    // 接口返回的数据获取
    window.jsonpCb = (res) => {
      document.body.removeChild(script)
      delete window.jsonpCb
      resolve(res)
    }
    script.src = `${url}?${handleData(data)}&cb=jsonpCb`
    document.body.appendChild(script)
  })
}
// 使用方式
request({
  url: 'http://localhost:9871/api/jsonp',
  data: {
    // 传参
    msg: 'helloJsonp'
  }
}).then(res => {
  console.log(res)
})

2.空iframe加form
细心的朋友可能发现,JSONP只能发GET请求,因为本质上script加载资源就是GET,那么如果要发POST请求怎么办呢?

后端写个小接口

// 处理成功失败返回格式的工具
const {successBody} = require('../utli')
class CrossDomain {
  static async iframePost (ctx) {
    let postData = ctx.request.body
    console.log(postData)
    ctx.body = successBody({postData: postData}, 'success')
  }
}
module.exports = CrossDomain

前端

const requestPost = ({url, data}) => {
  // 首先创建一个用来发送数据的iframe.
  const iframe = document.createElement('iframe')
  iframe.name = 'iframePost'
  iframe.style.display = 'none'
  document.body.appendChild(iframe)
  const form = document.createElement('form')
  const node = document.createElement('input')
  // 注册iframe的load事件处理程序,如果你需要在响应返回时执行一些操作的话.
  iframe.addEventListener('load', function () {
    console.log('post success')
  })

  form.action = url
  // 在指定的iframe中执行form
  form.target = iframe.name
  form.method = 'post'
  for (let name in data) {
    node.name = name
    node.value = data[name].toString()
    form.appendChild(node.cloneNode())
  }
  // 表单元素需要添加到主文档中.
  form.style.display = 'none'
  document.body.appendChild(form)
  form.submit()

  // 表单提交后,就可以删除这个表单,不影响下次的数据发送.
  document.body.removeChild(form)
}
// 使用方式
requestPost({
  url: 'http://localhost:9871/api/iframePost',
  data: {
    msg: 'helloIframePost'
  }
})

3.CORS

CORS是一个W3C标准,全称是"跨域资源共享"(Cross-origin resource sharing)跨域资源共享 CORS 详解。看名字就知道这是处理跨域问题的标准做法。CORS有两种请求,简单请求和非简单请求。

这里引用上面链接阮一峰老师的文章说明一下简单请求和非简单请求。
浏览器将CORS请求分成两类:简单请求(simple request)和非简单请求(not-so-simple request)。

只要同时满足以下两大条件,就属于简单请求。
(1) 请求方法是以下三种方法之一:

  • HEAD
  • GET
  • POST

(2)HTTP的头信息不超出以下几种字段:

  • Accept
  • Accept-Language
  • Content-Language
  • Last-Event-ID
  • Content-Type:只限于三个值application/x-www-form-urlencoded、multipart/form-data、text/plain

1.简单请求
后端

// 处理成功失败返回格式的工具
const {successBody} = require('../utli')
class CrossDomain {
  static async cors (ctx) {
    const query = ctx.request.query
    // *时cookie不会在http请求中带上
    ctx.set('Access-Control-Allow-Origin', '*')
    ctx.cookies.set('tokenId', '2')
    ctx.body = successBody({msg: query.msg}, 'success')
  }
}
module.exports = CrossDomain

前端什么也不用干,就是正常发请求就可以,如果需要带cookie的话,前后端都要设置一下,下面那个非简单请求例子会看到。

fetch(`http://localhost:9871/api/cors?msg=helloCors`).then(res => {
  console.log(res)
})

2.非简单请求
非简单请求会发出一次预检测请求,返回码是204,预检测通过才会真正发出请求,这才返回200。这里通过前端发请求的时候增加一个额外的headers来触发非简单请求。
clipboard.png

后端

// 处理成功失败返回格式的工具
const {successBody} = require('../utli')
class CrossDomain {
  static async cors (ctx) {
    const query = ctx.request.query
    // 如果需要http请求中带上cookie,需要前后端都设置credentials,且后端设置指定的origin
    ctx.set('Access-Control-Allow-Origin', 'http://localhost:9099')
    ctx.set('Access-Control-Allow-Credentials', true)
    // 非简单请求的CORS请求,会在正式通信之前,增加一次HTTP查询请求,称为"预检"请求(preflight)
    // 这种情况下除了设置origin,还需要设置Access-Control-Request-Method以及Access-Control-Request-Headers
    ctx.set('Access-Control-Request-Method', 'PUT,POST,GET,DELETE,OPTIONS')
    ctx.set('Access-Control-Allow-Headers', 'Origin, X-Requested-With, Content-Type, Accept, t')
    ctx.cookies.set('tokenId', '2')

    ctx.body = successBody({msg: query.msg}, 'success')
  }
}
module.exports = CrossDomain

一个接口就要写这么多代码,如果想所有接口都统一处理,有什么更优雅的方式呢?见下面的koa2-cors。

const path = require('path')
const Koa = require('koa')
const koaStatic = require('koa-static')
const bodyParser = require('koa-bodyparser')
const router = require('./router')
const cors = require('koa2-cors')
const app = new Koa()
const port = 9871
app.use(bodyParser())
// 处理静态资源 这里是前端build好之后的目录
app.use(koaStatic(
  path.resolve(__dirname, '../dist')
))
// 处理cors
app.use(cors({
  origin: function (ctx) {
    return 'http://localhost:9099'
  },
  credentials: true,
  allowMethods: ['GET', 'POST', 'DELETE'],
  allowHeaders: ['t', 'Content-Type']
}))
// 路由
app.use(router.routes()).use(router.allowedMethods())
// 监听端口
app.listen(9871)
console.log(`[demo] start-quick is starting at port ${port}`)

前端

fetch(`http://localhost:9871/api/cors?msg=helloCors`, {
  // 需要带上cookie
  credentials: 'include',
  // 这里添加额外的headers来触发非简单请求
  headers: {
    't': 'extra headers'
  }
}).then(res => {
  console.log(res)
})

4.代理
想一下,如果我们请求的时候还是用前端的域名,然后有个东西帮我们把这个请求转发到真正的后端域名上,不就避免跨域了吗?这时候,Nginx出场了。
Nginx配置

server{
    # 监听9099端口
    listen 9099;
    # 域名是localhost
    server_name localhost;
    #凡是localhost:9099/api这个样子的,都转发到真正的服务端地址http://localhost:9871 
    location ^~ /api {
        proxy_pass http://localhost:9871;
    }    
}

前端就不用干什么事情了,除了写接口,也没后端什么事情了

// 请求的时候直接用回前端这边的域名http://localhost:9099,这就不会跨域,然后Nginx监听到凡是localhost:9099/api这个样子的,都转发到真正的服务端地址http://localhost:9871 
fetch('http://localhost:9099/api/iframePost', {
  method: 'POST',
  headers: {
    'Accept': 'application/json',
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    msg: 'helloIframePost'
  })
})

Nginx转发的方式似乎很方便!但这种使用也是看场景的,如果后端接口是一个公共的API,比如一些公共服务获取天气什么的,前端调用的时候总不能让运维去配置一下Nginx,如果兼容性没问题(IE 10或者以上),CROS才是更通用的做法吧。

同源策略限制下Dom查询的正确打开方式

1.postMessage
window.postMessage() 是HTML5的一个接口,专注实现不同窗口不同页面的跨域通讯。
为了演示方便,我们将hosts改一下:127.0.0.1 crossDomain.com,现在访问域名crossDomain.com就等于访问127.0.0.1。

这里是http://localhost:9099/#/crossDomain,发消息方

<template>
  <div>
    <button @click="postMessage">给http://crossDomain.com:9099发消息</button>
    <iframe name="crossDomainIframe" data-original="http://crossdomain.com:9099"></iframe>
  </div>
</template>

<script>
export default {
  mounted () {
    window.addEventListener('message', (e) => {
      // 这里一定要对来源做校验
      if (e.origin === 'http://crossdomain.com:9099') {
        // 来自http://crossdomain.com:9099的结果回复
        console.log(e.data)
      }
    })
  },
  methods: {
    // 向http://crossdomain.com:9099发消息
    postMessage () {
      const iframe = window.frames['crossDomainIframe']
      iframe.postMessage('我是[http://localhost:9099], 麻烦你查一下你那边有没有id为app的Dom', 'http://crossdomain.com:9099')
    }
  }
}
</script>

这里是http://crossdomain.com:9099,接收消息方

<template>
  <div>
    我是http://crossdomain.com:9099
  </div>
</template>

<script>
export default {
  mounted () {
    window.addEventListener('message', (e) => {
      // 这里一定要对来源做校验
      if (e.origin === 'http://localhost:9099') {
        // http://localhost:9099发来的信息
        console.log(e.data)
        // e.source可以是回信的对象,其实就是http://localhost:9099窗口对象(window)的引用
        // e.origin可以作为targetOrigin
        e.source.postMessage(`我是[http://crossdomain.com:9099],我知道了兄弟,这就是你想知道的结果:${document.getElementById('app') ? '有id为app的Dom' : '没有id为app的Dom'}`, e.origin);
      }
    })
  }
}
</script>

结果可以看到:

clipboard.png

2.document.domain
这种方式只适合主域名相同,但子域名不同的iframe跨域。
比如主域名是http://crossdomain.com:9099,子域名是http://child.crossdomain.com:9099,这种情况下给两个页面指定一下document.domain即document.domain = crossdomain.com就可以访问各自的window对象了。

3.canvas操作图片的跨域问题
这个应该是一个比较冷门的跨域问题,张大神已经写过了我就不再班门弄斧了解决canvas图片getImageData,toDataURL跨域问题

最后

希望看完这篇文章之后,再有人问跨域的问题,你可以嘴角微微上扬,冷笑一声:“不要再问我跨域的问题了。”
扬长而去。

查看原文

monkeykg 收藏了文章 · 2019-08-13

谈谈Web应用中的图片优化技巧及反思

这篇文章,我们将一起探讨,web应用中能对图片进行什么样的优化,以及反思一些“负优化”手段

一、为什么要对图片进行优化

对于大多数前端工程师来说,图片就是UI设计师(或者自己)切好的图,你要做的只是把图片丢进项目中,然后用以链接的方式呈现在页面上,而且我们也经常把精力放在项目的打包优化构建上,如何分包,如何抽取第三方库........有时我们会忘了,图片才是一个网站最大头的那块加载资源(见下图),虽然图片加载可以不不阻碍页面渲染,但优化图片,绝对可以让网站的体验提升一个档次。

二、从图片大小开始优化

压缩图片可以使用统一的压缩工具 — imagemin,它是一款可以集成多个压缩库的工具,支持jpg,png,webp等等格式的图片压缩,比如pngquant,mozjpeg等等,作为测试用途,我们可以直接安装imagemin-pngquant来尝试png图片的压缩:

PNG压缩

    npm install imagemin
    npm install imagemin-pngquant

这里先安装imagemin库,再安装对应的png压缩库

    const imagemin = require('imagemin');
    const imageminPngquant = require('imagemin-pngquant');

    (async () => {
        await imagemin(['images/*.png'], 'build/images', {
            plugins: [
                imageminPngquant({ quality: '65-80' })
            ]
        });

        console.log('Images optimized');
    })();

我们可以在quailty一项决定压缩比率,65-80貌似是一个在压缩率和质量之间实现平衡的数值,腾讯AlloyTeam出品的gka图片处理工具,同样使用到了imagemin库,他们默认也是使用65-80的选项:
gka代码
用它压缩一张png图片,我们看看效果如何:

这是压缩前的:

这是压缩后的:

从肉眼上几乎看不出区别,但实际上减少了百分之77的体积!读者可以自己保存图片进行比较。

JPG/JPEG压缩与渐进式图片

压缩jpg/jpeg图片的方式与png类似,imagemin提供了两个插件:jpegtrain和mozjpeg供我们使用。一般我们选择mozjpeg,它拥有更丰富的压缩选项:

    npm install imagemin-mozjpeg
    const imagemin = require('imagemin');
    const imageminMozjpeg = require('imagemin-mozjpeg');

    (async () => {
        await imagemin(['images/*.jpg'], 'build/images', {
            use: [
                imageminMozjpeg({ quality: 65, progressive: true })
            ]
        });

        console.log('Images optimized');
    })();

注意到我们使用了progressive: true选项,这可以将图片转换为渐进式图片,关于渐进式图片,它允许在加载照片的时候,如果网速比较慢的话,先显示一个类似模糊有点小马赛克的质量比较差的照片,然后慢慢的变为清晰的照片:

渐进式图片

而相比之下,非渐进式的图片(Baseline JPEG)则会老老实实地从头到尾去加载:

Baseline JPEG

张鑫旭大神的这篇文章,可以帮你更好地了解两者的区别:
渐进式jpeg(progressive jpeg)图片及其相关
简单来说,渐进式图片一开始就决定了大小,而不像Baseline图片一样,不断地从上往下加载,从而造成多次回流,但渐进式图片需要消耗CPU去多次计算渲染,这是其主要缺点。
当然,交错式png也可以实现相应的效果,但目前pngquant没有实现转换功能,但是ps中导出png时是可以设置为交错式的。

在真实项目中如何操作?

实际项目中,总不能UI丢一个图过来你就跑一遍压缩代码吧?幸好imagemin有对应的webpack插件,在webpack遍地使用的今天,我们可以轻松实现批量压缩:

    npm install imagemin-webpack-plugin

先安装imagemin-webpack-plugin

    import ImageminPlugin from 'imagemin-webpack-plugin'
    import imageminMozjpeg from 'imagemin-mozjpeg'

    module.exports = {
      plugins: [
        new ImageminPlugin({
          plugins: [
            imageminMozjpeg({
              quality: 100,
              progressive: true
            })
          ]
        })
      ]
    }

接着在webpack配置文件中,引入自己需要的插件,使用方法完全相同。具体可参考github的文档imagemin-webpack-plugin

三、通过图片按需加载减少请求压力

图片按需加载是个老生常谈的话题,传统做法自然是通过监听页面滚动位置,符合条件了再去进行资源加载,我们看看如今还有什么方法可以做到按需加载。

使用强大的IntersectionObserver

IntersectionObserver提供给我们一项能力:可以用来监听元素是否进入了设备的可视区域之内,这意味着:我们等待图片元素进入可视区域后,再决定是否加载它,毕竟用户没看到图片前,根本不关心它是否已经加载了。
这是Chrome51率先提出和支持的API,而在2019年的今天,各大浏览器对它的支持度已经有所改善(除了IE,全线崩~):
IntersectionObserver的兼容性
废话不多说,上代码:
首先,假设我们有一个图片列表,它们的src属性我们暂不设置,而用data-src来替代:

<li>
  <img class="list-item-img" alt="loading" data-data-original='a.jpg'/>
</li>
<li>
  <img class="list-item-img" alt="loading" data-data-original='b.jpg'/>
</li>
<li>
  <img class="list-item-img" alt="loading" data-data-original='c.jpg'/>
</li>
<li>
  <img class="list-item-img" alt="loading" data-data-original='d.jpg'/>
</li>

这样会导致图片无法加载,这当然不是我们的目的,我们想做的是,当IntersectionObserver监听到图片元素进入可视区域时,将data-src"还给"src属性,这样我们就可以实现图片加载了:

const observer = new IntersectionObserver(function(changes) {
  changes.forEach(function(element, index) {
   // 当这个值大于0,说明满足我们的加载条件了,这个值可通过rootMargin手动设置
    if (element.intersectionRatio > 0) {
      // 放弃监听,防止性能浪费,并加载图片。
      observer.unobserve(element.target);
      element.target.src = element.target.dataset.src;
    }
  });
});
function initObserver() {
  const listItems = document.querySelectorAll('.list-item-img');
  listItems.forEach(function(item) {
   // 对每个list元素进行监听
    observer.observe(item);
  });
}
initObserver();

运行代码并观察控制台的Network,会发现图片随着可视区域的移动而加载,我们的目的达到了。

这里给出一个线上demo,供大家调试学习
(ps: 这里额外介绍一个vue的图片懒加载组件vue-view-lazy,也是基于IntersectionObserver实现的)。

还是Chrome的黑科技——loading属性

从新版本Chrome(76)开始,已经默认支持一种新的html属性——loading,它包含三种取值:auto、lazy和eager(ps: 之前有文章说是lazyload属性,后来chrome的工程师已经将其确定为loading属性,原因是lazyload语义不够明确),我们看看这三种属性有什么不同:

auto:让浏览器自动决定是否进行懒加载,这其中的机制尚不明确。

lazy:明确地让浏览器对此图片进行懒加载,即当用户滚动到图片附近时才进行加载,但目前没有具体说明这个“附近”具体是多近。

eager:让浏览器立刻加载此图片,也不是此篇文章关注的功能。

我们可以通过chrome的开发工具看看这个demo中的图片加载方式,我们把上一个demo中的js脚本都删掉了,只用了loading=lazy这个属性。接着,勾选工具栏中的Disabled Cache后仔细观察Network一栏,细心的人应该会发现,一张图片被分为了两次去请求!第一次的状态码是206,第二次的状态码才是200,如图所示:

这个现象跟chrome的lazy-loading功能的实现机制有关:

首先,浏览器会发送一个预请求,请求地址就是这张图片的url,但是这个请求只拉取这张图片的头部数据,大约2kb,具体做法是在请求头中设置range: bytes=0-2047,

而从这段数据中,浏览器就可以解析出图片的宽高等基本维度,接着浏览器立马为它生成一个空白的占位,以免图片加载过程中页面不断跳动,这很合理,总不能为了一个懒加载,让用户牺牲其他方面的体验吧?这个请求返回的状态码是206,表明:客户端通过发送范围请求头Range抓取到了资源的部分数据,详细的状态码解释可以看看这篇文章

然后,在用户滚动到图片附近时,再发起一个请求,完整地拉取图片的数据下来,这个才是我们熟悉的状态码200请求。

可以预测到,如果以后这个属性被普遍使用,那一个服务器要处理的图片请求连接数可能会变成两倍,对服务器的压力会有所增大,但时代在进步,我们可以依靠http2多路复用的特性来缓解这个压力,这时候就需要技术负责人权衡利弊了

要注意,使用这项特性进行图片懒加载时,记得先进行兼容性处理,对不支持这项属性的浏览器,转而使用JavaScript来实现,比如上面说到的IntersectionObserver:

    if ("loading" in HTMLImageElement.prototype) {
      // 没毛病
    } else {
      // .....
    }

还可以做到锦上添花!

以上介绍的两种方式,其实最终实现的效果是相似的,但这里还有个问题,当网速慢的时候,图片还没加载完之前,用户会看到一段空白的时间,在这段空白时间,就算是渐进式图片也无法发挥它的作用,我们需要更友好的展示方式来弥补这段空白,有一种方法简单粗暴,那就是用一张占位图来顶替,这张占位图被加载过一次后,即可从缓存中取出,无须重新加载,但这种图片会显得有些千篇一律,并不能很好地做到preview的效果。
这里我向大家介绍另一种占位图做法——css渐变色背景,原理很简单,当img标签的图片还没加载出来,我们可以为其设置背景色,比如:

    <img data-original="a.jpg" style="background: red;"/>

这样会先显示出红色背景,再渲染出真实的图片,重点来了,我们此时要借用工具为这张图片"配制"出合适的渐变背景色,以达到部分preview的效果,我们可以使用https://calendar.perfplanet.com/2018/gradient-image-placeholders/ 这篇文章中推荐的工具GIP进行转换,这里附上在线转换的地址https://tools.w3clubs.com/gip/
经过转换后,我们得到了下面这串代码:

    background: linear-gradient(
      to bottom,
      #1896f5 0%,
      #2e6d14 100%
    )

最终效果如下所示:

四、响应式图片的实践

我们经常会遇到这种情况:一张在普通笔记本上显示清晰的图片,到了苹果的Retina屏幕或是其他高清晰度的屏幕上,就变得模糊了。

这是因为,在同样尺寸的屏幕上,高清屏可以展示的物理像素点比普通屏多,比如Retina屏,同样的屏幕尺寸下,它的物理像素点的个数是普通屏的4倍(2 * 2),所以普通屏上显示清晰的图片,在高清屏上就像是被放大了,自然就变得模糊了,要从图片资源上解决这个问题,就需要在设备像素密度为2的高清屏中,对应地展示一张两倍大小的图。

而通常来讲,对于背景图片,我们可以使用css的@media进行媒体查询,以决定不同像素密度下该用哪张倍图,例如:

    .bg {
        background-image: url("bg.png");
        width: 100px;
        height: 100px;
        background-size: 100% 100%;
    }
    @media (-webkit-min-device-pixel-ratio: 2),(min-device-pixel-ratio: 2)
    {
        .bg {
            background-image: url("bg@2x.png") // 尺寸为200 * 200的图
        }
    }

这么做有两个好处,一是保证高像素密度的设备下,图片仍能保持应有的清晰度,二是防止在低像素密度的设备下加载大尺寸图片造成浪费。

那么如何处理img标签呢?

我们可以使用HTML5中img标签的srcset来达到这个效果,看看下面这段代码:

    <img width="320"  data-original="bg@2x.png" srcset="bg.png 1x;bg@2x.png 2x"/>

这段代码的作用是:当设备像素密度,也就是dpr(devicePixelRatio)为1时,使用bg.png,为2时使用二倍图bg@2x.png,依此类推,你可以根据需要设置多种精度下要加载的图片,如果没有命中,浏览器会选择最邻近的一个精度对应的图片进行加载。
要注意:老旧的浏览器不支持srcset的特性,它会继续正常加载src属性引用的图像。

五、安全地使用WebP图片

WebP的优势这里不再赘述,简单来说就是:同样尺寸的图片,WebP能保证比未压缩过的png、jpg、gif等格式的图片减少百分之40-70(甚至90)的比例,且保证较高的质量,更可以支持显示动态图和透明通道。

但目前WebP的兼容性并不太好:

但我们可以通过两种方式,对暂未支持webp的浏览器进行兼容:

picture结合source标签

HTML5的picture标签,可以理解为相框,里面可以支持多种格式的图片,并保留一张默认底图:

    <picture>
      <source srcset="bg.webp" type="image/webp">
      <source srcset="bg.jpg" type="image/jpeg"> 
      <img data-original="bg.jpg" alt="背景图">
    </picture>

有了这段代码,浏览器会自动根据是否支持webp格式来选择加载哪张图片,若不支持,则会显示bg.jpg,如果浏览器连picture都不支持,那么会fallback到默认的img图片,这是必不可少的一个选项。

而且这里要注意source的放置顺序,如果把jpg放在第一位,webp放在第二位,即使浏览器支持webp,那也会选择加载jpg图片。

借助cdn服务自动判断

目前,有些图片cdn服务可以开启自动兼容webp的模式,即支持webp的浏览器则将原图转换为webp图片并返回,否则直接返回原图。实现这个功能的原理是,根据浏览器发起的请求头中的Accept属性中是否包含webp格式来判断:

有则说明浏览器支持webp格式,这对开发者来说可能是最简单的兼容方案,但是依赖于后端服务。

接下来,谈一谈我认为应该反思的负优化手段:

六、对Base64Url的反思

首先复习一下Base64的概念,Base64就是一种基于64个可打印字符来表示二进制数据的方法,编码过程是从二进制数据到字符串的过程,在web应用中我们经常用它来做啥呢——传输图片数据。HTML中,img的src和css样式的background-image都可以接受base64字符串,从而在页面上渲染出对应的图片。正是基于浏览器的这项能力,很多开发者提出了将多张图片转换为base64字符串,放进css样式文件中的“优化方式”,这样做的目的只有一个——减少HTTP请求数。但实际上,在如今的应用开发中,这种做法大多数情况是“负优化”效果,接下来让我们细数base64 Url的“罪状”:

第一、让css文件的体积失去控制

当你把图片转换为base64字符串之后,字符串的体积一般会比原图更大,一般会多出接近3成的大小,如果你一个页面中有20张平均大小为50kb的图片,转它们为base64后,你的css文件将可能增大1.2mb的大小,这样将严重阻碍浏览器的关键渲染路径:

css文件本身就是渲染阻塞资源,浏览器首次加载时如果没有全部下载和解析完css内容就无法进行渲染树的构建,而base64的嵌入则是雪上加霜,这将把原先浏览器可以进行优化的图片异步加载,变成首屏渲染的阻塞和延迟。

或许有人会说,webpack的url-loader可以根据图片大小决定是否转为base64(一般是小于10kb的图片),但你也应该担心如果页面中有100张小于10kb的图片时,会给css文件增加多少体积。

第二、让浏览器的资源缓存策略功亏一篑

假设你的base64Url会被你的应用多次复用,本来浏览器可以直接从本地缓存取出的图片,换成base64Url,将造成应用中多个页面重复下载1.3倍大小的文本,假设一张图片是100kb大小,被你的应用使用了10次,那么造成的流量浪费将是:(100 1.3 10) - 100 = 1200kb。

第三、低版本浏览器的兼容问题

这是比较次要的问题,dataurl在低版本IE浏览器,比如IE8及以下的浏览器,会有兼容性问题,详细情况可以参考这篇文章

第四、不利于开发者工具调试与查看

无论哪张图片,看上去都是一堆没有意义的字符串,光看代码无法知道原图是哪张,不利于某些情况下的比对。

说了这么多,有人可能不服气,既然这种方案缺点这么多,为啥它会从以前就被广泛使用呢?这要从早期的http协议特性说起,在http1.1之前,http协议尚未实现keep-alive,也就是每一次请求,都必须走三次握手四次挥手去建立连接,连接完又丢弃无法复用,而即使是到了http1.1的时代,keep-alive可以保证tcp的长连接,不需要多次重新建立,但由于http1.1是基于文本分割的协议,所以消息是串行的,必须有序地逐个解析,所以在这种请求“昂贵”,且早期图片体积并不是特别大,用户对网页的响应速度和体验要求也不是很高的各种前提结合下,减少图片资源的请求数是可以理解的。

但是,在越来越多网站支持http2.0的前提下,这些都不是问题,h2是基于二进制帧的协议,在保留http1.1长连接的前提下,实现了消息的并行处理,请求和响应可以交错甚至可以复用,多个并行请求的开销已经大大降低,我已经不知道还有什么理由继续坚持base64Url的使用了。

总结

图片优化的手段总是随着浏览器特性的升级,网络传输协议的升级,以及用户对体验要求的提升而不停地更新迭代,几年前适用的或显著的优化手段,几年后不一定仍然如此。因地制宜,多管齐下,才能将其优化做到极致!

ps:欢迎关注微信公众号——前端漫游指南,会定期发布优质原创文章和译文,关注公众号福利:回复666可以获得精选前端进阶电子书,感谢~

图片描述

查看原文

monkeykg 赞了文章 · 2019-08-13

谈谈Web应用中的图片优化技巧及反思

这篇文章,我们将一起探讨,web应用中能对图片进行什么样的优化,以及反思一些“负优化”手段

一、为什么要对图片进行优化

对于大多数前端工程师来说,图片就是UI设计师(或者自己)切好的图,你要做的只是把图片丢进项目中,然后用以链接的方式呈现在页面上,而且我们也经常把精力放在项目的打包优化构建上,如何分包,如何抽取第三方库........有时我们会忘了,图片才是一个网站最大头的那块加载资源(见下图),虽然图片加载可以不不阻碍页面渲染,但优化图片,绝对可以让网站的体验提升一个档次。

二、从图片大小开始优化

压缩图片可以使用统一的压缩工具 — imagemin,它是一款可以集成多个压缩库的工具,支持jpg,png,webp等等格式的图片压缩,比如pngquant,mozjpeg等等,作为测试用途,我们可以直接安装imagemin-pngquant来尝试png图片的压缩:

PNG压缩

    npm install imagemin
    npm install imagemin-pngquant

这里先安装imagemin库,再安装对应的png压缩库

    const imagemin = require('imagemin');
    const imageminPngquant = require('imagemin-pngquant');

    (async () => {
        await imagemin(['images/*.png'], 'build/images', {
            plugins: [
                imageminPngquant({ quality: '65-80' })
            ]
        });

        console.log('Images optimized');
    })();

我们可以在quailty一项决定压缩比率,65-80貌似是一个在压缩率和质量之间实现平衡的数值,腾讯AlloyTeam出品的gka图片处理工具,同样使用到了imagemin库,他们默认也是使用65-80的选项:
gka代码
用它压缩一张png图片,我们看看效果如何:

这是压缩前的:

这是压缩后的:

从肉眼上几乎看不出区别,但实际上减少了百分之77的体积!读者可以自己保存图片进行比较。

JPG/JPEG压缩与渐进式图片

压缩jpg/jpeg图片的方式与png类似,imagemin提供了两个插件:jpegtrain和mozjpeg供我们使用。一般我们选择mozjpeg,它拥有更丰富的压缩选项:

    npm install imagemin-mozjpeg
    const imagemin = require('imagemin');
    const imageminMozjpeg = require('imagemin-mozjpeg');

    (async () => {
        await imagemin(['images/*.jpg'], 'build/images', {
            use: [
                imageminMozjpeg({ quality: 65, progressive: true })
            ]
        });

        console.log('Images optimized');
    })();

注意到我们使用了progressive: true选项,这可以将图片转换为渐进式图片,关于渐进式图片,它允许在加载照片的时候,如果网速比较慢的话,先显示一个类似模糊有点小马赛克的质量比较差的照片,然后慢慢的变为清晰的照片:

渐进式图片

而相比之下,非渐进式的图片(Baseline JPEG)则会老老实实地从头到尾去加载:

Baseline JPEG

张鑫旭大神的这篇文章,可以帮你更好地了解两者的区别:
渐进式jpeg(progressive jpeg)图片及其相关
简单来说,渐进式图片一开始就决定了大小,而不像Baseline图片一样,不断地从上往下加载,从而造成多次回流,但渐进式图片需要消耗CPU去多次计算渲染,这是其主要缺点。
当然,交错式png也可以实现相应的效果,但目前pngquant没有实现转换功能,但是ps中导出png时是可以设置为交错式的。

在真实项目中如何操作?

实际项目中,总不能UI丢一个图过来你就跑一遍压缩代码吧?幸好imagemin有对应的webpack插件,在webpack遍地使用的今天,我们可以轻松实现批量压缩:

    npm install imagemin-webpack-plugin

先安装imagemin-webpack-plugin

    import ImageminPlugin from 'imagemin-webpack-plugin'
    import imageminMozjpeg from 'imagemin-mozjpeg'

    module.exports = {
      plugins: [
        new ImageminPlugin({
          plugins: [
            imageminMozjpeg({
              quality: 100,
              progressive: true
            })
          ]
        })
      ]
    }

接着在webpack配置文件中,引入自己需要的插件,使用方法完全相同。具体可参考github的文档imagemin-webpack-plugin

三、通过图片按需加载减少请求压力

图片按需加载是个老生常谈的话题,传统做法自然是通过监听页面滚动位置,符合条件了再去进行资源加载,我们看看如今还有什么方法可以做到按需加载。

使用强大的IntersectionObserver

IntersectionObserver提供给我们一项能力:可以用来监听元素是否进入了设备的可视区域之内,这意味着:我们等待图片元素进入可视区域后,再决定是否加载它,毕竟用户没看到图片前,根本不关心它是否已经加载了。
这是Chrome51率先提出和支持的API,而在2019年的今天,各大浏览器对它的支持度已经有所改善(除了IE,全线崩~):
IntersectionObserver的兼容性
废话不多说,上代码:
首先,假设我们有一个图片列表,它们的src属性我们暂不设置,而用data-src来替代:

<li>
  <img class="list-item-img" alt="loading" data-data-original='a.jpg'/>
</li>
<li>
  <img class="list-item-img" alt="loading" data-data-original='b.jpg'/>
</li>
<li>
  <img class="list-item-img" alt="loading" data-data-original='c.jpg'/>
</li>
<li>
  <img class="list-item-img" alt="loading" data-data-original='d.jpg'/>
</li>

这样会导致图片无法加载,这当然不是我们的目的,我们想做的是,当IntersectionObserver监听到图片元素进入可视区域时,将data-src"还给"src属性,这样我们就可以实现图片加载了:

const observer = new IntersectionObserver(function(changes) {
  changes.forEach(function(element, index) {
   // 当这个值大于0,说明满足我们的加载条件了,这个值可通过rootMargin手动设置
    if (element.intersectionRatio > 0) {
      // 放弃监听,防止性能浪费,并加载图片。
      observer.unobserve(element.target);
      element.target.src = element.target.dataset.src;
    }
  });
});
function initObserver() {
  const listItems = document.querySelectorAll('.list-item-img');
  listItems.forEach(function(item) {
   // 对每个list元素进行监听
    observer.observe(item);
  });
}
initObserver();

运行代码并观察控制台的Network,会发现图片随着可视区域的移动而加载,我们的目的达到了。

这里给出一个线上demo,供大家调试学习
(ps: 这里额外介绍一个vue的图片懒加载组件vue-view-lazy,也是基于IntersectionObserver实现的)。

还是Chrome的黑科技——loading属性

从新版本Chrome(76)开始,已经默认支持一种新的html属性——loading,它包含三种取值:auto、lazy和eager(ps: 之前有文章说是lazyload属性,后来chrome的工程师已经将其确定为loading属性,原因是lazyload语义不够明确),我们看看这三种属性有什么不同:

auto:让浏览器自动决定是否进行懒加载,这其中的机制尚不明确。

lazy:明确地让浏览器对此图片进行懒加载,即当用户滚动到图片附近时才进行加载,但目前没有具体说明这个“附近”具体是多近。

eager:让浏览器立刻加载此图片,也不是此篇文章关注的功能。

我们可以通过chrome的开发工具看看这个demo中的图片加载方式,我们把上一个demo中的js脚本都删掉了,只用了loading=lazy这个属性。接着,勾选工具栏中的Disabled Cache后仔细观察Network一栏,细心的人应该会发现,一张图片被分为了两次去请求!第一次的状态码是206,第二次的状态码才是200,如图所示:

这个现象跟chrome的lazy-loading功能的实现机制有关:

首先,浏览器会发送一个预请求,请求地址就是这张图片的url,但是这个请求只拉取这张图片的头部数据,大约2kb,具体做法是在请求头中设置range: bytes=0-2047,

而从这段数据中,浏览器就可以解析出图片的宽高等基本维度,接着浏览器立马为它生成一个空白的占位,以免图片加载过程中页面不断跳动,这很合理,总不能为了一个懒加载,让用户牺牲其他方面的体验吧?这个请求返回的状态码是206,表明:客户端通过发送范围请求头Range抓取到了资源的部分数据,详细的状态码解释可以看看这篇文章

然后,在用户滚动到图片附近时,再发起一个请求,完整地拉取图片的数据下来,这个才是我们熟悉的状态码200请求。

可以预测到,如果以后这个属性被普遍使用,那一个服务器要处理的图片请求连接数可能会变成两倍,对服务器的压力会有所增大,但时代在进步,我们可以依靠http2多路复用的特性来缓解这个压力,这时候就需要技术负责人权衡利弊了

要注意,使用这项特性进行图片懒加载时,记得先进行兼容性处理,对不支持这项属性的浏览器,转而使用JavaScript来实现,比如上面说到的IntersectionObserver:

    if ("loading" in HTMLImageElement.prototype) {
      // 没毛病
    } else {
      // .....
    }

还可以做到锦上添花!

以上介绍的两种方式,其实最终实现的效果是相似的,但这里还有个问题,当网速慢的时候,图片还没加载完之前,用户会看到一段空白的时间,在这段空白时间,就算是渐进式图片也无法发挥它的作用,我们需要更友好的展示方式来弥补这段空白,有一种方法简单粗暴,那就是用一张占位图来顶替,这张占位图被加载过一次后,即可从缓存中取出,无须重新加载,但这种图片会显得有些千篇一律,并不能很好地做到preview的效果。
这里我向大家介绍另一种占位图做法——css渐变色背景,原理很简单,当img标签的图片还没加载出来,我们可以为其设置背景色,比如:

    <img data-original="a.jpg" style="background: red;"/>

这样会先显示出红色背景,再渲染出真实的图片,重点来了,我们此时要借用工具为这张图片"配制"出合适的渐变背景色,以达到部分preview的效果,我们可以使用https://calendar.perfplanet.com/2018/gradient-image-placeholders/ 这篇文章中推荐的工具GIP进行转换,这里附上在线转换的地址https://tools.w3clubs.com/gip/
经过转换后,我们得到了下面这串代码:

    background: linear-gradient(
      to bottom,
      #1896f5 0%,
      #2e6d14 100%
    )

最终效果如下所示:

四、响应式图片的实践

我们经常会遇到这种情况:一张在普通笔记本上显示清晰的图片,到了苹果的Retina屏幕或是其他高清晰度的屏幕上,就变得模糊了。

这是因为,在同样尺寸的屏幕上,高清屏可以展示的物理像素点比普通屏多,比如Retina屏,同样的屏幕尺寸下,它的物理像素点的个数是普通屏的4倍(2 * 2),所以普通屏上显示清晰的图片,在高清屏上就像是被放大了,自然就变得模糊了,要从图片资源上解决这个问题,就需要在设备像素密度为2的高清屏中,对应地展示一张两倍大小的图。

而通常来讲,对于背景图片,我们可以使用css的@media进行媒体查询,以决定不同像素密度下该用哪张倍图,例如:

    .bg {
        background-image: url("bg.png");
        width: 100px;
        height: 100px;
        background-size: 100% 100%;
    }
    @media (-webkit-min-device-pixel-ratio: 2),(min-device-pixel-ratio: 2)
    {
        .bg {
            background-image: url("bg@2x.png") // 尺寸为200 * 200的图
        }
    }

这么做有两个好处,一是保证高像素密度的设备下,图片仍能保持应有的清晰度,二是防止在低像素密度的设备下加载大尺寸图片造成浪费。

那么如何处理img标签呢?

我们可以使用HTML5中img标签的srcset来达到这个效果,看看下面这段代码:

    <img width="320"  data-original="bg@2x.png" srcset="bg.png 1x;bg@2x.png 2x"/>

这段代码的作用是:当设备像素密度,也就是dpr(devicePixelRatio)为1时,使用bg.png,为2时使用二倍图bg@2x.png,依此类推,你可以根据需要设置多种精度下要加载的图片,如果没有命中,浏览器会选择最邻近的一个精度对应的图片进行加载。
要注意:老旧的浏览器不支持srcset的特性,它会继续正常加载src属性引用的图像。

五、安全地使用WebP图片

WebP的优势这里不再赘述,简单来说就是:同样尺寸的图片,WebP能保证比未压缩过的png、jpg、gif等格式的图片减少百分之40-70(甚至90)的比例,且保证较高的质量,更可以支持显示动态图和透明通道。

但目前WebP的兼容性并不太好:

但我们可以通过两种方式,对暂未支持webp的浏览器进行兼容:

picture结合source标签

HTML5的picture标签,可以理解为相框,里面可以支持多种格式的图片,并保留一张默认底图:

    <picture>
      <source srcset="bg.webp" type="image/webp">
      <source srcset="bg.jpg" type="image/jpeg"> 
      <img data-original="bg.jpg" alt="背景图">
    </picture>

有了这段代码,浏览器会自动根据是否支持webp格式来选择加载哪张图片,若不支持,则会显示bg.jpg,如果浏览器连picture都不支持,那么会fallback到默认的img图片,这是必不可少的一个选项。

而且这里要注意source的放置顺序,如果把jpg放在第一位,webp放在第二位,即使浏览器支持webp,那也会选择加载jpg图片。

借助cdn服务自动判断

目前,有些图片cdn服务可以开启自动兼容webp的模式,即支持webp的浏览器则将原图转换为webp图片并返回,否则直接返回原图。实现这个功能的原理是,根据浏览器发起的请求头中的Accept属性中是否包含webp格式来判断:

有则说明浏览器支持webp格式,这对开发者来说可能是最简单的兼容方案,但是依赖于后端服务。

接下来,谈一谈我认为应该反思的负优化手段:

六、对Base64Url的反思

首先复习一下Base64的概念,Base64就是一种基于64个可打印字符来表示二进制数据的方法,编码过程是从二进制数据到字符串的过程,在web应用中我们经常用它来做啥呢——传输图片数据。HTML中,img的src和css样式的background-image都可以接受base64字符串,从而在页面上渲染出对应的图片。正是基于浏览器的这项能力,很多开发者提出了将多张图片转换为base64字符串,放进css样式文件中的“优化方式”,这样做的目的只有一个——减少HTTP请求数。但实际上,在如今的应用开发中,这种做法大多数情况是“负优化”效果,接下来让我们细数base64 Url的“罪状”:

第一、让css文件的体积失去控制

当你把图片转换为base64字符串之后,字符串的体积一般会比原图更大,一般会多出接近3成的大小,如果你一个页面中有20张平均大小为50kb的图片,转它们为base64后,你的css文件将可能增大1.2mb的大小,这样将严重阻碍浏览器的关键渲染路径:

css文件本身就是渲染阻塞资源,浏览器首次加载时如果没有全部下载和解析完css内容就无法进行渲染树的构建,而base64的嵌入则是雪上加霜,这将把原先浏览器可以进行优化的图片异步加载,变成首屏渲染的阻塞和延迟。

或许有人会说,webpack的url-loader可以根据图片大小决定是否转为base64(一般是小于10kb的图片),但你也应该担心如果页面中有100张小于10kb的图片时,会给css文件增加多少体积。

第二、让浏览器的资源缓存策略功亏一篑

假设你的base64Url会被你的应用多次复用,本来浏览器可以直接从本地缓存取出的图片,换成base64Url,将造成应用中多个页面重复下载1.3倍大小的文本,假设一张图片是100kb大小,被你的应用使用了10次,那么造成的流量浪费将是:(100 1.3 10) - 100 = 1200kb。

第三、低版本浏览器的兼容问题

这是比较次要的问题,dataurl在低版本IE浏览器,比如IE8及以下的浏览器,会有兼容性问题,详细情况可以参考这篇文章

第四、不利于开发者工具调试与查看

无论哪张图片,看上去都是一堆没有意义的字符串,光看代码无法知道原图是哪张,不利于某些情况下的比对。

说了这么多,有人可能不服气,既然这种方案缺点这么多,为啥它会从以前就被广泛使用呢?这要从早期的http协议特性说起,在http1.1之前,http协议尚未实现keep-alive,也就是每一次请求,都必须走三次握手四次挥手去建立连接,连接完又丢弃无法复用,而即使是到了http1.1的时代,keep-alive可以保证tcp的长连接,不需要多次重新建立,但由于http1.1是基于文本分割的协议,所以消息是串行的,必须有序地逐个解析,所以在这种请求“昂贵”,且早期图片体积并不是特别大,用户对网页的响应速度和体验要求也不是很高的各种前提结合下,减少图片资源的请求数是可以理解的。

但是,在越来越多网站支持http2.0的前提下,这些都不是问题,h2是基于二进制帧的协议,在保留http1.1长连接的前提下,实现了消息的并行处理,请求和响应可以交错甚至可以复用,多个并行请求的开销已经大大降低,我已经不知道还有什么理由继续坚持base64Url的使用了。

总结

图片优化的手段总是随着浏览器特性的升级,网络传输协议的升级,以及用户对体验要求的提升而不停地更新迭代,几年前适用的或显著的优化手段,几年后不一定仍然如此。因地制宜,多管齐下,才能将其优化做到极致!

ps:欢迎关注微信公众号——前端漫游指南,会定期发布优质原创文章和译文,关注公众号福利:回复666可以获得精选前端进阶电子书,感谢~

图片描述

查看原文

赞 53 收藏 36 评论 4

monkeykg 赞了文章 · 2019-07-29

[译] 写给前端工程师的 Docker 入门

为什么我们要用 docker ?

过去的我们,当业务发展需要部署新的应用时,DevOps 小伙伴通常会去买一台服务器,但是却不知道这个新应用具体需要多高的配置,往往都会造成资源浪费。

当虚拟机出现后,它可以让我们在一台服务器上运行多个应用,但是却有一个缺陷。每个 VM 需要运行一整个的操作系统。每个 OS 又需要 CPU、RAM 等等,需要打补丁、安装证书,这些反过来又增加了成本和弹性。

Google 在很久之前就开始使用容器模型来解决 VM 模式的弊端。简单来说容器模型允许我们在同一台主机上运行多个容器,而且共用主机的 CPU、RAM 等资源。

那么它对开发者来说意味着是么呢?

它可以保证对所有的开发者和服务器来说,我们的工作环境都是一致的。比如: 生产环境、仿真环境、测试环境。

任何人都可以分分钟配置好项目,无需乱搞配置、安装库和设置依赖。

简单来说,docker 是一个平台,它允许我们使用容器来开发、部署、运行应用程序。

让我们退一步来看,容器系统在物理上是什么样子的,以及与 VM 有什么区别。

1-vm-and-docker.png

可以看出来,宿主机的资源在容器化的使用后是共享的,但是在 VM 中却被分割开了。

接下来,我们来深入一些。

如何使用 docker ?

为此我们需要先熟悉一些术语。

2-images-and-container.png

Docker image: 它是一个可执行文件,包含了运行一个应用程序的操作系统配置和所有的库。它有多个层叠在一起,并表示为单个对象。docker image 是通过 docker file 来创建的,我们稍后再讲。

Docker Container: 它是 docker image 的一个运行实例。同一个 docker image 可以有多个运行的 container。

容器化 Node.js 应用

我们来尝试容器化一个简单的 node.js 应用,然后创建一个 image:

你的 Node.js 应用

先创建一个 my-node-app 文件夹,

mkdir my-node-app
cd my-node-app

然后创建一个 index.js 来启动一个 node server:

// 我们用 require 引入 express

var express = require('express')

var app = express()

// 对根 URL 做一个响应
app.get('/', function (req, res) {  
 res.send('Hello World!')  
})

// 让服务器监听 8081 端口
app.listen(8081, function () {  
  console.log('app listening on port 8081!')  
})

然后我们创建一个 package.json 文件,可以通过 npm init -y 来快速生成:

 {

    "name": "helloworld",  
    "version": "1.0.0",  
    "description": "Dockerized node.js app",  
    "main": "index.js",  
    "author": "",  
    "license": "ISC",  
    "dependencies": {  
      "express": "^4.16.4"  
    }
 }

到这一步我们甚至不需要 express 或者 npm 安装在自己的机器,因为 dockerfile 可以为我们配置和安装这些依赖。

DockerFile

让我们创建一个 dockerfile,然后保存到 my-node-app 文件夹。这个文件没有扩展名,它的名字就叫作 Dockerfile,这是里面的内容:

# Dockerfile
FROM node:8
WORKDIR /app
COPY package.json /app
RUN npm install
COPY . /app
EXPOSE 8081
CMD node index.js

下面解释一下里面的命令:

FROM node:8 -- 从 docker hub 拉取 node.js docker 镜像,可以在这里找到 node 的镜像:https://hub.docker.com/_/node/

WORKDIR /app -- 设置镜像中的工作目录,可以与下面的命令一起使用: COPYRUNCMD

COPY package.json /app -- 将 package.json 从宿主机的 my-node-app 目录复制到了镜像中的 /app 目录

RUN npm install -- 在镜像中运行此命令来安装 node 包

COPY . /app -- 复制 my-node-app 目录中的所有文件到镜像中的 /app 目录

EXPOSE 8081 -- 这条命令告诉 container 要暴露一个端口号,这个端口号正是我们在 index.js 中写的那个。默认情况下,容器会忽略对它所有的请求。

构建 Docker 镜像

注意看啦~ 打开控制台,到 my-node-app 目录下,执行以下命令:

 # Build a image docker build -t <image-name> <relative-path-to-your-dockerfile>

 docker build -t hello-world .

这条命令在我们宿主机创建了一个 hello-world 镜像

-t 用来为我们的镜像指定一个名字,这里就是 hello-world

. 是用来指明 docker file 的路径,由于我们已经在 my-node-app 中,所以路径用 . 就可以了

你可以在控制台看到类似于以下的输出:

Sending build context to Docker daemon  4.096kB  
Step 1/7 : FROM node:8  
 ---> 4f01e5319662  
Step 2/7 : WORKDIR /app  
 ---> Using cache  
 ---> 5c173b2c7b76  
Step 3/7 : COPY package.json /app  
 ---> Using cache  
 ---> ceb27a57f18e  
Step 4/7 : RUN npm install  
 ---> Using cache  
 ---> c1baaf16812a  
Step 5/7 : COPY . /app  
 ---> 4a770927e8e8  
Step 6/7 : EXPOSE 8081  
 ---> Running in 2b3f11daff5e  
Removing intermediate container 2b3f11daff5e  
 ---> 81a7ce14340a  
Step 7/7 : CMD node index.js  
 ---> Running in 3791dd7f5149  
Removing intermediate container 3791dd7f5149  
 ---> c80301fa07b2  
Successfully built c80301fa07b2  
Successfully tagged hello-world:latest

可以看到,它根据 docker file 中的命令依次运行,然后输出了一个 docker 镜像。当你第一次运行的时候可能会需要一些时间,下次就可以使用缓存来加快速度了。现在我们来看下刚才 build 的镜像:

 # Get a list of images on your host 
 docker images

这个命令会显示在你电脑上存在的 docker 镜像。其中会有一条:

REPOSITORY    TAG      IMAGE ID      CREATED         SIZE  
hello-world   latest   c80301fa07b2  22 minutes ago  896MB

运行 Docker 容器

既然我们已经创建了镜像,下面我们就从这个镜像运行一个 docker 容器:

# Default command for this is docker container run <image-name>  
 docker container run -p 4000:8081 hello-world

这条命令用来创建和运行一个 docker 容器

-p 4000:8081 -- 是一个发布(publish)标识,它将本机的 4000 端口映射到了容器中的 8081 端口。现在所有对本机 4000 端口的访问,都会被容器中的 8081 端口监听。

hello-world -- 这个名字就是刚才用 docker build 命令时指定的镜像名称。

你将会得到以下输出:

app listening on port 8081!

如果你需要进入容器并且挂载一个 bash 终端,可以运行:

# Enter the container
docker exec -ti <container id> /bin/bash

为了检查我们的容器是否运行,打开另一个命令行,然后输入:

docker ps

可以看到以下输出:


 CONTAINER ID    IMAGE        COMMAND                  CREATED    
 `<container id>`  hello-world  "/bin/sh -c 'node in…"   11 seconds ago

 STATUS              PORTS                    NAMES  
 Up 11 seconds       0.0.0.0:4000->8081/tcp   some-random-name

这里可以看我们从 hello-world 镜像创建的容器,以及它的 <container id> ,它正在运行,并且监听了 8081 端口号。

现在我们这个简单的 Node.js 应用就已经完全容器化了。你可以在浏览器访问 http://localhost:4000 ,应该可以看到以下画面:

3-localhost.png

看,是不是很简单哈哈~

原文链接


欢迎关注我的公众号:码力全开(codingonfire)
codingonfire.jpg

查看原文

赞 153 收藏 111 评论 13

monkeykg 关注了问题 · 2019-07-24

使用iview的select组件进行远程搜索时,编辑功能出了问题,不能选定默认值。

<FormItem label="负责人:" prop="chargeUserId">

        <Select v-model="cubForm.chargeUserId" 
                filterable clearable remote :remote-method="remoteMethod2"
                :loading="loading2">
          <Option v-for="item in userList" :key="item.id" :value="item.id" :label="item.name"
                  style="width: 250px">
          </Option>
        </Select>

</FormItem>

      
  这个是远程搜索的方法    
    remoteMethod2(query) { 
    let self = this;
      if (query) {
        self.loading2 = true;
        let params = {
          name: query
        }
        this.$api.get("/user/search", {params: params}).then(function (res) {
          if (res.data.code === 200) {
            self.userList = res.data.data.list;
          } else {
            self.$Message.error('获取数据失败!' + res.data.code);
          }
        })
        this.loading2 = false;
      }
  },
  
  初始化的时候 userList已经push了默认的对象,页面也显示了

clipboard.png
可是当我点击这个select框 再点击空白处的时候,select框内的值就不见了,而且无法再选中默认的值(图中即“nishuo”这个值)。
clipboard.png

clipboard.png

关注 5 回答 4

monkeykg 关注了问题 · 2019-07-19

解决Document This注释插件能支持vue文件吗?

  1. 编辑器是vscode,安装了document this注释插件,但是只支持html和js文件,无法在vue文件中使用。
  2. 如何在vue文件中使用document this插件,或者有没有替代方案?

关注 5 回答 3

monkeykg 关注了用户 · 2019-01-12

william @liwenjie_59a4eecc51e6a

love and share

关注 224

monkeykg 关注了专栏 · 2019-01-12

前端进阶之路

love and share

关注 595

monkeykg 关注了标签 · 2018-12-12

react.js

React (sometimes styled React.js or ReactJS) is an open-source JavaScript library for creating user interfaces that aims to address challenges encountered in developing single-page applications. It is maintained by Facebook, Instagram and a community of individual developers and corporations.

关注 69849

认证与成就

  • 获得 83 次点赞
  • 获得 2 枚徽章 获得 0 枚金徽章, 获得 0 枚银徽章, 获得 2 枚铜徽章

擅长技能
编辑

开源项目 & 著作
编辑

(゚∀゚ )
暂时没有

注册于 2018-01-26
个人主页被 654 人浏览