最近无聊就会改动我的实时播放页面的玩意(推不动黄油就折腾东西)...为了让博客有点更新的样子,我还是在这里写一下一些笔记吧,以防以后忘记。

先说说目前的更改吧...现在姑且算是做出了个模样(至少能看得下)

1.专辑图和背景图同步之后,背景添加淡入效果
2.将专辑图的图源改回官方的Akamai CDN,然而 WebP 不知如何适配
3.尝试全站启用 Brotli 压缩算法(没啥显著效果)
4.对静态资源进行 DNS 预取 (没啥显著效果)
5.新增个人 Last.fm 实时信息查看 (做不出提示框的效果)

关于 官方CDN 与反代中转的取舍和 WebP 的适配

CDN

Last.fm 是用世界上最大的分布式计算平台之一的 Akamai 作为 CDN,知名度比较高,虽然国内也有节点,可惜 lastfm 似乎没使用国内节点(反正国内体验一般),而且之前访问的时候,直接选择走德国的节点,延迟和速度有点慢。虽然这个人页面没人访问,就我自己自嗨而已,不过不让自己的体验降到最低,还是处理一下吧。

于是我选择了反向代理作为中转,并进行缓存。毕竟服务器放在西海岸速度和延迟似乎还行,不过啊还是担心负载,一到晚上国际出口繁忙的时候,体验跟官方CDN差不多,而且大图片再中转,传输等待的时候就长了不少,还不如直接用官方CDN。

想过要不要用七牛云或又拍云作为中转...然而..七牛云的测试域名不支持HTTPS,又拍云新申请的服务也不会提供HTTPS(只剩一个旧测试域名可以用HTTPS)(然而我没备案,很亏)。既然用不了https,那就直接靠反代过去吧...emmm,考虑到多种因素,还是放弃吧...(又拍云CDN回源不知如何配置,想过七牛云和又拍云的融合云同步再进行反代,哇一个图片走4个服务器,没什么意义了)

昨天我心血来潮再试试看看官方CDN的速度,发现节点不走欧洲了,都走亚太地区和美国那边了,那就改回去吧..少折腾了。

WebP

WebP 是一种同时提供了有损压缩与无损压缩(可逆压缩)的图片文件格式。与其他图片格式相比,WebP 集合了多种图片文件格式的特点。它像 JPEG 一样适合压缩照片和其他细节丰富的图片,像 GIF 一样可以显示动态图片,像 PNG 一样支持透明图像。(引用又拍云的介绍

当初试用 WebP 在博客的效果很赞,至少加载速度快了不少(七牛云的CDN可以开启WebP适配,开了就行不用管那啥)。在第一版的时候,我把专辑图的后缀名全部替换改成webp,这样速度快了不少,至少刚开始加载的背景图跟动画效果完美配合。于是我就把做好的页面分享给群里的大佬,但有个大佬访问后截了个网页截图,怎么背景都是黑的。这就奇怪了,难道是代码不兼容?

后来看了下WebP的兼容性,哇,就只有 Chrome/Opera 和国产 Chromium 核浏览器支持,其他Edge和火狐都兼容,这就很尴尬了,那边的厂商就这么吝啬不用谷歌的图像格式吗?

但是用 jpg 的话,虽然我可以利用akamai的图片处理将地址替换成 800px 或其他等比像素图像,但是啊..还是WebP的加载快啊。怎么办,那就去适配啊

WebPJS 效果不好看

用WebPJS的话,通过swf来让其他浏览器显示webp文件,可惜这js实在是有点大(70k),而且使用的画面效果不好看(尤其是背景图不继承我的css)。

用 JQuery 改后缀名 ?

Akamai是有类似又拍云的图像处理,可以改图片的后缀名就能发送相应的content-type。然而啊,akamai好像没有又拍云那种可以自适应不同客户端,你只能改webp或jpg,就算这个浏览器不支持他也不会帮你适配..这就很骚了。

那就...干脆用懒加载?既然可以随意更改后缀名显示不同格式的图像,那就访问的时候自动适配改名呗。然后谷歌一下看到了 WebP-lazyLoad,比较适合我的需求,可...似乎有点麻烦,自己能力有限,还是留着等以后处理(而且我也不知道懒加载支不支持动态效果的页面)

只怪自己能力不足。现在姑且用着jpg格式吧,大图的速度还是可以的

曲线救国

既然自己能力不足,那就只能转个弯实现了啊。现在可以根据浏览器适配webp的cdn只有又拍云和魔门云,其他忽略。使用它们的功能需要备案才行啊。。。

但...现在不是有免费的已备案二级域名吗...直接找个好看的二级备案域名用着不就可以了吗?然后赶紧申请了一个。丢到又拍云的CDN申请...等了一下午才审核完(审核也太慢了吧)..然后再申请一个SSL证书..终于!可以用了。。

源站 → 又拍云CDN → 页面,可能第一次获取图片的时候会比较慢,不过一旦缓存下来了,基本上就不用担心什么速度了。

可想而知,走webp,整体加载速度的质变有多大
20171217222707.jpg

开启 Brotli 压缩算法

前天又拍云发了份广告邮件给我:启用 Brotli 压缩算法,对比 Gzip 压缩 CDN 流量再减少 20%

Google 认为互联网用户的时间是宝贵的,他们的时间不应该消耗在漫长的网页加载中,因此在 2015 年 9 月 Google 推出了无损压缩算法 Brotli。Brotli 通过变种的 LZ77 算法、Huffman 编码以及二阶文本建模等方式进行数据压缩,与其他压缩算法相比,它有着更高的压缩效率。

看起来好像还行,于是给 nginx 重新编译了一下并且启用了,然而个人体感一般,没啥明显效果,相比于 GZip,容量也只是少了0.1K。好在gzip和brotli可以共存,所以就这样放着吧。
20171216205106.jpg

个人 Last.fm 实时信息查看

让我重新改回那个jquery脚本似乎有点困难(不想折腾),那就..上网找个范例改改算了。。

获取跨域资源,很多情况都是会选择 AJAX 获取远程数据,就像本站的PJAX也是AJAX的改版而已,这个实时页面的核心文件也是完全靠AJAX。既然不想在原本的脚本基础上修改的话,那就拿个AJAX对GET JSON异步请求的范例做下修改就可以了

原理:

 $.getJSON(
       url,                 //请求URL
       [data],           //传参,可选参数
       [callback]       //回调函数,可选参数
    ); 

还好 last.fm 的api会预生成json和xml,不用进行后端处理直接调用就行了。利用我的ws.goubi.me进行反代中转就行了
20171216211015.jpg

这蛋疼的背景图淡入处理

之前的版本,虽然做到了背景图和专辑图的同步,但因为加载速度,让背景图加载的时候变得比较难看(加载的时候背景一片马赛克)。

于是看了下 Github 的同类 last.fm 的实时播放的相关项目,看到了 JasonPuglisi/lastfm-now 的实时页面对背景图的处理比较好。大概原理是:背景图也跟专辑图同步→当换歌的时候,背景图会提前消失→通过延时让背景图稍后显示,并带淡入效果
这个可以有(赞赏).jpg。这样就不用担心加载过程的尴尬效果了。

然而为了实现了这个功能,花了一晚上才搞定,主要是之前的逻辑有点问题。

之前我对背景图的处理是这样的:

 var $bg = $(".bg").css(xxxxx).addClass("animated fadeIn"); //更改内嵌相应的样式,并且添加淡入效果
    $('.bg').removeAttr('style').removeClass('animated fadeIn');//当换歌的时候删掉 bg 类的内嵌 css 

这就导致一个问题,只有第一次加载的时候才能出现淡入效果,然后换歌的时候,并没有淡入效果,而且图片加载还是跟以前那样难看。大概原因是换歌的时候,bg的style换得太快,删了也很快替换下一首歌的专辑图,而且animated fadeIn只会执行一次,除非你删掉整个类再换上新的bg。

对哦,为什么不参考这jquery的原理呢?当换歌的时候,“listitem”会自动删掉,并且利用appendTo重新插入新的HTML内容。而且,换歌的时候,动画效果会随着新生成的元素实现淡入淡出..啊如果早点想出来的话我现在早就去推黄油了23333

于是现在是这样处理背景图的:

var $bg = $("<div>").css(xxxx}).addClass("bg animated fadeIn").appendTo('.prebg'); //利用AppendTo(在被选元素的结尾(仍然在内部)插入指定内容),在prebg中插入新的bg类
$('.bg').remove(); (换歌的时候,将整个bg类删掉,等待换歌完毕后重新加入) 

在动画方面,利用css自带的延迟和动画持续效果(-webkit-animation-delay/duration),实现稍后展示的效果。

结语

反正这实时页面也不会有人会看,自己自嗨而已。但如果能实现自己的想法,还是挺好的