数图项目添加PWA特性记录

在vipkid工作两年多,项目要求80%的用户能达到1s秒开,数图项目加载优化进行了很多变,从协议到图片裁剪到 dns prefetch 关键资源 preload 等等一系列操作,平均用户首页的加载时间为1130ms .

但是满足80%的用户达到秒开,始终差了那么一点点,这个周六周日,抽出时间利用worbox 来为数图增加pwa 特性,看看是否能够帮助项目完成指标,周一进行上线。

待续

最大内容绘制(Largest Contentful Paint)译

原文链接:https://web.dev/largest-contentful-paint/

Largest Contentful Paint 这个指标让我们知道一个页面的重要的内容变得更加容易。

一直以来,对于web开发者来说,测量一个web页面的主要内容加载多快,渲染的速度多快,是个挑战。

老的测量指标,例如load DOMContentLoaded 并不算一个好的测量指标,这个指标并不能清楚的测量用户在屏幕上看到了什么。performance 中的First Paint(FTP) 和 First Contentful Paint(FCP) 仅仅只能捕获加载阶段的最初页面。如果一个页面正在展示启动页面,或者加载进度条,这个东西其实与用户无关。

阅读 “最大内容绘制(Largest Contentful Paint)译”

gzip与brotli压缩算法对比

网传的压缩比

上面这幅图是比各种无损压缩算法的压缩比,其中提到brotli压缩比gzip的要高。最近一直搞新版数图首页的优化,新版数图的首页各种资源加起来有3.6MB ,各种优化手段都使用上,基本上连1个RTT的时延都不想放弃,当然经过有,数图首页的加载时间基本上平均在948ms内。其中利用到阿里云的cdn服务。

阿里云目前的cdn服务开始支持quic协议(实验性质的),目前这个估计是在收集用户数据。和运维的同学一系列的沟通,终于说服他们在这个星期开启了cdn 支持TLS1.3协议并开启brotli压缩算法

阅读 “gzip与brotli压缩算法对比”

在wireshark中查看https http2包内容的配置方法

当我们web服务启用TLS协议之后,我们通过wireshark抓包是无法查看应用层的数据的,看到的是加密过后的数据。这个时候如果我们拥有https网站的加密私钥,我们可以来解密改网站的加密流量,此外Firfox 和Chrome支持将TLS会话中使用的对称密钥保存在文件中,这个可以为wireshark使用,也可以查看TLS加密的数据。现在我们来看第二种方式操作方式。

阅读 “在wireshark中查看https http2包内容的配置方法”

东京行

浅草寺

春娟同学趁着五一假期,约我去日本走走,为了强迫自己办理签证,我先定好机票然后办理签证,签证过程中一波三折,终于赶在4月28日拿到签证,4月29日早上的机票,好险!

自己第一次出国,攻略我是一点都没有做,只是在网上偶尔看了看,当时都没有考虑在外面手机怎么通信,春娟买了个移动wifi,28日下午,我查了一下,是可以购买流量卡的,这个比移动wifi更加好用,马上淘宝查了一下北京的地区的商家,自己直接打个车去取流量卡,其实坐地铁更快 -_-!

阅读 “东京行”

sourcemap 上传到sentry异常监控系统的配置记录

前端异常监控和性能监控基本是web开发的标配了,很多公司都开发自己的异常监控和页面性能监控系统,sentry是个不错的开源的性能监控平台,功能丰富,还能和gitlab ,钉钉等各个平台进行结合,将异常监控上报到gitlab或与钉钉机器人结合,这对于一般公司来说,够用了,这对于线上前端出现的异常能够实时的发现,修复。

基于sentry的基础配置就不多说了,本文的目的就是怎么将sourcemap上传到sentry服务中去,让技术人员在分析异常的时,更加方便。

将js的sourcemap文件上传到sentry 有如下三种方法,1.realases API, 2.sentry-cli 3, sentry-webpack-plugin 都可以达到我们的目的。

现在我们来通过第三种方式来实现sourcemaps文件上传到sentry服务中。我以vue-cli3的配置来一步步实现配置。阅读 “sourcemap 上传到sentry异常监控系统的配置记录”

10月的故宫

北平之秋就是人间的天堂,也许比天堂更繁荣一点呢!

有人说春住杭州,夏住青城,秋住北京,冬住昆明,秋天的北京也许是人家的天堂,没有雾霾的时候,天蓝的清澈,☁️如棉花糖一天躺在天上。

长安街上的汽车

一个人一路小跑,在一个大风的日子,又游了一遍故宫。阅读 “10月的故宫”

一致性hash算法在分布式缓存服务中的应用

示意图

上一篇文章,我利用redis缓存来减轻数据库的压力,但是我这仍然是个在同一台服务器,开了redis缓存服务。在现在那些高并发的下,并保证高可用性的环境下,基本会将redis服务部署在不同机器上,当并发过多的时候,单点的redis服务很难保证高可用性,假如机器宕机,那么怎么办?假如缓存数量上亿计,查询对应的缓存列表也会耗时,这样也会导致延迟。这个时候很容易想到我们设置多台缓存服务器,当一台缓存服务器宕机的时候,然后请求发到没有宕机的缓存服务器上,但是又碰到了一个问题,我们怎么将请求打在对应缓存服务器中,假如同一个请求过来一次,请求的还是上一次请求的缓存服务器。阅读 “一致性hash算法在分布式缓存服务中的应用”