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

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

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

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

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

我们之前推荐使用 peformanceAPI 中的First Meaningful Paint(FMP)Speed Index(SI)帮助我们了解初次渲染之后加载信息。但是这些指标复杂,难以解释,并经常出错,他们无法准确的描述页面的主要内容什么时候已经加载好

有时候越简单越好。基于在W3C Web Performance Working Group上的讨论,以及在Google做的研究。我们已经发现一个更准确的方式去测量一个页面的主要内容是否已经加载出来,该方式就是看页面的绝大部分元素是否已经渲染出来

Largest Contentful Paint 的定义

Largest Contentful Paint(LCP) API在chrome 77 中已经有了。 它用来指示最大内容元素能够在可视窗口显示出来,需要的渲染时间

哪些元素需要考虑在内呢?

一般来讲,Largest Contentful Paint 考虑到如下元素。

  • img 元素
  • 内嵌在svg中的image元素
  • video元素(使用到封面图片)
  • 拥有背景图片的元素(通过url()方式)
  • 包含文本节点或或行内文本节点的块级元素

注意,目前只是现在这些元素能够在模型建立之初保持模型简单,随着研究的深入,其他的元素元素也会被添加进来。

如何确定一个元素的大小?

为Largest Contentful Paint 所采用的元素的大小通常是用户在viewport中可见的大小。如果该元素超出可视区域,或者该元素不可见,或者该元素被裁剪,这些情况都不算该元素的尺寸。

对于图片元素来说,如果显示的大小和图片的固有尺寸不一样,如果图片原始尺寸比显示的图片尺寸小,那么图片元素的尺寸采取图原始尺寸,如果显示的尺寸比图片的原始尺寸小,那么报告的图片的显示尺寸。

对于文本元素来说,只需要考虑所有文本节点的大小(所有文本节点撑起来最小的矩形)

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算法在分布式缓存服务中的应用”

alonehero.com站点优化记录

lighthouse测评

夜空中最亮的星的个人站点,虽然是一个,cpu为单核,运行内存为1G ,带宽为2Mb的个人wordpress站点,但是经过自己几天的优化,访问的响应速度大大提高,First Contentful Panit 比之前快了将近400ms,

当然跟那些并发上百亿的服务比是天壤之别,但是优化的点还是可以记录下的。

这边正的要感谢阿里云的快速发展,让任何人配置自己的站点更加容易。在这个优化过程中,用的阿里云产品有云服务器,CDN服务,证书服务,OSS存储服务,性能测试服务,快照服务。

阅读 “alonehero.com站点优化记录”