Performance

  • 我们通过分析主流浏览器Chrome,来了解一个脚本从无到有再到运行作用,到底经历了什么。以下将会用lodash为作为例子,浏览器的脚本生命周期。

    HTML解析

    在浏览器中,在HTML解析过程中,当解析到带有srcscript标签,便会即刻调度网络模块队列,网络模块在有空余请求线程时,会即刻执行队列的请求。

    举个栗子:

    <script>
    	console.log("Hello Tmall")
    </script>
    <script src="lodash.js"></script>
    

    浏览器会优先发起lodash.js的请求,而后执行console.

  • 在大家的认知里,JSONP,往往是另外一种异步请求的方式,其主要优点是支持跨域数据请求。因此,JSONP往往是将一个Script节点动态插入document,随后浏览器会自动发起一个远程请求。

    除了上述单一用法外,在PCWeb,JSONP具有非常巨大的性能&工程化价值。

    1.异步JSONP

    通过【图说舌尖上的脚本】与【同步vs异步加载】了解到,PCWeb受限于插件环境,异步机制变得非常不吃香。异步发起的请求,无论是JSONP等资源加载,抑或XHR(fetch),都会被标记为低优先级。

    • 同步插件脚本加载完才能发起请求
    • 在主进程的编译与执行前,会被插件脚本抢占。

    我们来看一下,发起6个

  • 同步与异步加载,往往是指网络资源,像图片、样式、脚本等。本文探索在PCWeb下,同步&异步性能差距到底有多少?为何移动端的优秀方案到PCWeb,会造成性能问题?

    同步加载

    我们只声明单一的静态脚本资源。

    <script src="./react.js"><script>
    

    异步加载

    使用简单脚本发起资源请求。

    <script>
    	var s = document.createElement('script')
    	s.src="./react.js"
    	document.body.appendChild(s)
    </script>
    

    结果

  • JS、CSS以及img对DOMContentLoaded事件的影响

    最近在做性能有关的数据上报,发现了两个非常有意思的东西:Chrome开发者工具的Timeline分析面板,以及DOMContentLoaded事件。一个是强大的令人发指的性能分析工具,一个是重要的性能指标,于是就用Timeline对DOMContentLoaded事件进行了一番研究。

    前端的纯技术就是对规范的认知

    什么是DOMContentLoaded事件?

    首先想到的是查看W3C的HTML5规范,DOMContentLoaded事件在什么时候触发:

    Once the user agent stops parsing the

  • 前言

    前端框架时代,为开发体验、效率与页面性能带来,非常大的革命。大家纷纷拿起一系列打包工具(webpack/parcel etc.),配合一系列加载器快速搭建起一个 SPA 页面。

    SPA 应用带来的好处非常明显;

    • 提升页面切换体验
    • 降低切换时间
    • 易于部署&前后端分离

    但是也带来一系列性能问题:

    • 初始加载脚本较大
    • 首屏空白时间较长
    • 页面返回时,数据被动重新拉取

    这些问题是使用 SPA 模式不可避免的,通过了解 SPA 加载运行过程,可以逐渐看清楚引起性能问题的根本原因,通过精细化应用加载,来解决这些问题。

    SPA 之殇

    愈发发福

    比起一般的简单页面,SPA 最大的问题,就是在