Service Worker实现浏览器端页面渲染或CSS,JS编译

这篇文章发布于 2018年04月24日,星期二,22:49,归类于 JS实例。 阅读 34227 次, 今日 3 次 15 条评论

 

Service Worker与在线编译banner图

Service Worker提供了一种能力,可以fetch请求的资源,然后后Service Worker中进行编译或转化,返回处理后的其他资源,这种特性可以用来实现各种资源的在线的客户端编译,本文就将抛砖引玉,通过两个应用案例,展示未来web开发可能的面貌。

一、Service Worker与直接数据和HTML模板渲染页面

现在很多网站的页面是基于Node.js直接渲染输出的,以实现完全的前后端分离,而这种渲染本质上还是在服务端进行的,只是渲染的语言是JavaScript。

实际上,有了Service Worker,我们可以直接在客户端,也就是浏览器里面直接进行渲染,优点是……乍一想,其实没什么特别的优点,无非是传输的HTML页面的体积小了,不过这点优化的体积就像是隔靴搔痒,杯水车薪,不值一提。但后来有一想,不对啊,这HTML编译全在客户端执行,岂不是省了很多服务器,为公司省了很多钱,因为烧的都是用户的电。

而且,毕竟是另外的一种解决思路,保不准某些场景下能大放异彩呢,抛砖引玉嘛,重在能力展示。

我们先看实际例子,您可以狠狠地点击这里:Service Worker与客户端渲染HTML渲染页面demo

打开一看,就是个列表,而且数据还是2012年北京蔬菜价格什么鬼?首先,数据什么的不是重点,只从为了节约时间从这篇文章“基于HTML模板和JSON数据的JavaScript交互”弄过来的,

这个页面玄机的要看开发文件源代码才行(右键页面源代码都不行):https://github.com/zhangxinxu/https-demo/tree/master/online-render

可以看到,index.html文件源代码列表明明是模板语法:

html开发源代码

但是我们右键页面,查看HTML源代码的时候确是真实的列表内容:

html在线编译后的页面源代码

为什么会发生这么神奇的事情?玄机就是Service Worker在背后做了HTML的数据渲染。

首先,注册Service Worker,代码如下:

if ('serviceWorker' in navigator) {
    navigator.serviceWorker.register('./sw-reader.js', {
        scope: './'
    });
}

然后关键就是sw-reader.js(访问点击这里),做了两件事情:

  1. 内置极简模板渲染引擎,采用的是老版本的artTemplate,大小仅2.3K。截图如下:

    模板渲染方法截图

  2. 捕获.html的请求,并对获取到的的HTML字符内容进行模板渲染,并返回输出。完成JS代码如下:
    self.addEventListener('fetch', function(event) {
      event.respondWith(async function () {
        if (/\.html/.test(event.request.url)) {
          let res = await fetch(event.request);
          let text = await res.text();
          
          var data = {};
          // 过滤JSON数据,使不暴露给用户
          text = text.replace(/([\w\W]*?)<\/script>/, function (matchs, $1) {
            // 获取页面渲染的JSON数据
            data = JSON.parse($1);
            return '';
          });
          // 模板text和数据data进行渲染并重新返回给浏览器
          return new Response(template.compile(text)(data), {
            headers: {
              'content-type': 'text/html; charset=utf-8'
            }
          });
        }
        return fetch(event.request);
      }());
    });
  3. 也就是变量text是原始的HTML代码,而在Service Worker中返回的是template.compile(text)(data)渲染后的HTML代码,于是,浏览器中呈现的就是最终的列表数据而非原始模板HTML。

在本demo中,我是将页面需要的JSON数据放在了模板页面头部,并使用<script type="text/json">进行标示,截图如下:

JSON数据标识

sw-reader.js中就是匹配<script type="text/json">获取JSON数据来进行渲染的。当然,你也可以使用其他标识,例如,前后都3个美元符号包起来进行识别,例如:

$$${
   list: []
}$$$

就是不怎么雅观。OK,小例子,抛砖引玉,下面看另外一个对静态资源进行编译的例子。

二、Service Worker与浏览器直接CSS编译

CSS一些预编译工具,例如,Less,Stylus都是使用JavaScript进行编译的,而这些编译工具都是有web版的,因此,理论上我们是可以把Less,Stylus的编译直接搬到浏览器客户端里面,然后我们就不用加载CSS文件了,直接加载less文件,Service Worker中编译成CSS并返回,页面也是可以正常访问的。

然后,问题在于,Less,Stylus的web版解析器体积有些大,压缩后还有150多K,个人觉得成本有点高了。

Less的JS尺寸

为了快速书写,我自己弄了个名为Qcss的编译工具,可以讲CSS声明自定义为缩写,以实现写CSS代码如马踏飞燕,例如:

.class-a { dib; w100; tc; }

可以实时转换成:

.class-a {
  display: inline-block;
  width: 100px;
  text-align: center;
}

而这个编译的JS方法提及非常小,仅2K多一点,和less的JS代码量相比简直就是毛毛雨,因此非常使用用在Service Worker实现一个可以在线编译CSS的功能。

先看例子,您可以狠狠地点击这里:Qcss和Service Worker在浏览器中编译成CSS demo

我们打开控制台查看网络请求,会发现,页面请求的是qcss文件,而不是传统的css文件:

请求的是qcss文件

而这个qcss文件原始代码是这样的:

qcss原始代码

全是一些CSS属性和属性值的缩写,但是,我们在demo页面查看qcss.test的请求数据,却是正统的CSS代码,截图示意如下:

源代码是CSS代码

同样的,也是Service Worker在浏览器背后编译的功劳,注册Service Worker的JS文件的核心代码如下:

var qcss=function(b){ /*qcss编译为css方法* /};

self.addEventListener('fetch', function(event) {
  event.respondWith(async function () {
    if (/\.qcss/.test(event.request.url)) {
      let res = await fetch(event.request);
      let text = await res.text();
      return new Response(qcss(text), {
        headers: {
          'content-type': 'text/css; charset=utf-8'
        }
      });
    }
    return fetch(event.request);
  }());
});

对吧,通俗易懂,一路了然。

这种在线编译有什么好处呢?例如省流量,test.qcss文件为7K多,而test.css文件则14K多,相比传统CSS文件传输体积小了50%,注意,这已经是压缩后的CSS再减小50%体积,根据自己测试,减小的体积在30%~50%之间(选择器越简洁压缩率越高)。

想想看,要是公司产品所有CSS都变成Qcss,传输小30%~50%,估计可以给公司省不少流量钱。

为此,我特意又写了个Node.js工具,可以把CSS文件转换成QCSS文件:https://github.com/zhangxinxu/gulp-qcss/blob/master/css2qcss.js

一个压缩器,一个解析器,外加Service Worker,就可以颠覆目前的CSS资源加载策略,对于一些无关紧要的小项目活动页面之类的,大家其实可以试试这种新技术,验证其价值。

关于QCSS解析及压缩,以后时机成熟我会专门介绍,这里,抛砖引玉,为大家的技术选项实践提供更开阔的思路。

三、Service Worker与浏览器直接JS编译

例如,我们可以把CoffeeScript直接搬到浏览器中,与上面类似,这里不进一步展开。

四、结束语

理论上,有了Service Worker,我们可以把很多很多Node.js的能力搬到客户端搬到浏览器中,不仅仅是离线缓存,不仅仅是模拟并伪造ajax请求数据,可谓是有了Service Worker,真的可以为所欲为。

有了技术能力,剩下的就是发挥我们的创造力和想象力,让我们的web开发策略更加繁荣昌盛。

还是那句话,本文旨在抛砖引玉,本文提供的两个demo的技术策略并不一定是最优解,也并不一定适合实际项目,尤其大型项目,可能会有风险。也欢迎大家集思广益,提供更好更佳的相关事件,我会在文中及时进行更新。

以上~

感谢阅读!

(本篇完)

分享到:


发表评论(目前15 条评论)

  1. 渲染说道:

    旭大神,可以分享一下浏览器渲染页面的流程吗?往上每次查资料,感觉写的都不是很靠谱呀

  2. 小书匠说道:

    666.学到了.

  3. 张 鑫旭说道:

    兼容性貌似还存在点问题

  4. 你今天真好看说道:

    嗯,看着你右上角的广告轮播图超烦人的,又不能关掉。
    于是F12审查元素,把那一段代码删掉了。
    嗯,这下干净了,继续看。

  5. 小媒体说道:

    文章很不错,之前也想过,不过美中不足的是,SEO依然不行,百度不会解析JS部分,按照渲染完的内容去收录建立索引。

  6. kingShen说道:

    get

  7. im333说道:

    用着东西渲染,会影响百度收录吗

  8. jiangwei说道:

    就怕移动端跑不动

  9. da li说道:

    了解了….

  10. iamakn说道:

    留下,学一会

  11. GoStop说道:

    关注下,万一火了呢

  12. 渣渣罗说道:

  13. ferrinweb说道:

    错别字:
    为了快速书写,我自己弄了个名为Qcss的编译工具,可以→讲←CSS声明自定义为缩写