xml地图|网站地图|网站标签 [设为首页] [加入收藏]

正规赌博十大app排名

当前位置:网上十大正规赌博平台 > 正规赌博十大app排名 > 快速提升前端性能,到页面加载完成的过程中都

快速提升前端性能,到页面加载完成的过程中都

来源:http://www.nb-machinery.com 作者:网上十大正规赌博平台 时间:2019-11-08 02:54

从输入 URL 到页面加载完成的过程中都发生了什么事情?

2015/10/03 · HTML5, JavaScript · 6 评论 · HTTP, 浏览器

原文出处: 百度FEX/吴多益(@吴多益)   

背景  本文来自于之前我发的一篇微博:

图片 1

不过写这篇文章并不是为了帮大家准备面试,而是想借这道题来介绍计算机和互联网的基础知识,让读者了解它们之间是如何关联起来的。

为了便于理解,我将整个过程分为了六个问题来展开。

大型单页面应用的进阶挑战

2015/09/30 · HTML5, JavaScript · 单页应用

原文出处: 林子杰(@Zack__lin)   

阅读须知:这里的大型单页面应用(SPA Web App)是指页面和功能组件在一个某个量级以上,举个栗子,比如 30 个页面100 个组件,同时伴随着大量的数据交互操作和多个页面的数据同步操作。并且这里提到的页面,均属于 hash 页面,而多页面概念的页面,是一个独立的 html 文档。基于这个前提,我们再来讨论,否则我怕我们 Get 不到同一个 G 点上去。

快速提升前端性能

2015/09/26 · HTML5, JavaScript · 1 评论 · 性能

本文由 伯乐在线 - cucr 翻译,唐尤华 校稿。未经许可,禁止转载!
英文出处:Jonathan Suh。欢迎加入翻译组。

去年,我写了一篇文章Need for Speed,分享了在开发我的网站中使用的工作流程和技术(包含工具)。从那时起,我的网站又经过了一次重构,完成了很多工作流程和服务器端改进,同时我对前端性能也给与了额外关注。以下就是我做的工作,为什么我要这么做,以及我在网站上用来优化前端性能的工具。

第一个问题:从输入 URL 到浏览器接收的过程中发生了什么事情?

挑战一:前端组件化

基于我们所说的前提,第一个面对的挑战是组件化。这里还是要强调的是组件化根本目的不是为了复用,很多人根本没想明白这点,总是觉得造的轮子别的业务可以用,说不定以后也可以用。

其实前端发展迭代这么快,交互变化也快,各种适配更新层出不穷。今天造的轮子,过阵子别人造了个高级轮子,大家都会选更高档的轮子,所以现在前端界有一个现象就是为了让别人用自己的轮子,自己使劲不停地造。

在前端工业化生产趋势下,如果要提高生产效率,就必须让组件规范化标准化,达到怎样的程度呢?一辆车除了底盘和车身框架需要自己设计打造之外,其他标准化零件都可以采购组装(专业学得差,有啥谬误请指正)。也就是说,除了 UI 和前端架构需要自己解决之外,其他的组件都是可以奉行拿来主义的,如果打算让车子跑得更稳更安全,可以对组件进行打磨优化完善。

说了这么说,倒不如看看徐飞的文章《2015前端组件化框架之路》 里面写的内容都是经过一定实践得出的想法,所以大部分内容我是赞成而且深有体会的。

最小化请求

所有在你的网站加载时用来渲染页面(外部CSS或JS文件、web字体、图片等等)的资源,都是不同的HTTP请求。一般的网站平均有 93个请求!

我的目标是减少HTTP请求。一种方法是分别编译或连接(组合、合并)CSS和javascript到一个文件中。让这个过程自动化(例如使用构建工具 Grunt 或 Gulp)是理想的效果,但至少也应该在生产环境下手动完成。

第三方脚本是增加额外请求最常见的罪魁祸首,很多获取额外的文件如脚本、图像或CSS的请求都不止1个。浏览器内置的开发者工具可以帮助你发现这些元凶。

图片 2
Google Chrome开发者工具的网络选项卡

例如,Facebook的脚本发起3次请求。测试环境中使用一些来自著名社交网站的社交分享脚本,可以看到他们快速增加:

站点 文件 大小
Google 1 15.1KB
Facebook 3 73.3KB
LinkedIn 2 47.7KB
Pinterest 3 12.9KB
Tumblr 1 1.5KB
Twitter 4 52.7KB
Total 14 203.2KB

来源:更有效的社会分享链接

这有额外的14个HTTP请求,共203.2KB。相反,我看看 “share-intent” 这个url,它基本上是通过传递和构建数据来生成一个共享,可以只使用HTML来创建社交共享链接。它让我丢掉用于共享的第三方脚本,这些脚本需要7次请求。我在Responsible Social Share Links这篇文章有更多的阐述。

评估每一个第三方脚本并确定其重要性。也许存在一种不依赖第三方的方法来完成它。你可能会失去一些功能(例如like、tweet、分享数量),但是请问一下自己:“像数量统计就那么重要吗?”

从触屏到 CPU

首先是「输入 URL」,大部分人的第一反应会是键盘,不过为了与时俱进,这里将介绍触摸屏设备的交互。

触摸屏一种传感器,目前大多是基于电容(Capacitive)来实现的,以前都是直接覆盖在显示屏上的,不过最近出现了 3 种嵌入到显示屏中的技术,第一种是 iPhone 5 的 In-cell,它能减小了 0.5 毫米的厚度,第二种是三星使用的 On-cell 技术,第三种是国内厂商喜欢用的 OGS 全贴合技术,具体细节可以阅读这篇文章。

当手指在这个传感器上触摸时,有些电子会传递到手上,从而导致该区域的电压变化,触摸屏控制器芯片根据这个变化就能计算出所触摸的位置,然后通过总线接口将信号传到 CPU 的引脚上。

以 Nexus 5 为例,它所使用的触屏控制器是 Synaptics S3350B,总线接口为 I²C,以下是 Synaptics 触摸屏和处理器连接的示例:图片 3

左边是处理器,右边是触摸屏控制器,中间的 SDA 和 SCL 连线就是 I²C 总线接口。

挑战二:路由去中心化

基于我们所说的前提,中心化的路由维护起来很坑爹(如果做一两个页面 DEMO 的就没必要出来现眼了)。MV* 架构就是存在这么个坑爹的问题,需要声明中心化 route(angular 和 react 等都需要先声明页面路由结构),针对不同的路由加载哪些组件模块。一旦页面多起来,甚至假如有人偷懒直接在某个路由写了一些业务耦合的逻辑,这个 route 的可维护性就变得有些糟糕了。而且用户访问的第一个页面,都需要加载 route,即使其他路由的代码跟当前页面无关。

我们再回过头来思考静态页面简单的加载方式。我们只要把 nginx 搭起来,把 html 页面放在对应的静态资源目录下,启动 nginx 服务后,在浏览器地址栏输入 127.0.0.1:8888/index.html 就可以访问到这个页面。再复杂一点,我们把目录整成下面的形式:

/post/201509151800.html /post/201509151905.html /post/201509152001.html /category/js_base_knowledge.html /category/css_junior_use.html /category/life_is_beautiful.html

1
2
3
4
5
6
/post/201509151800.html
/post/201509151905.html
/post/201509152001.html
/category/js_base_knowledge.html
/category/css_junior_use.html
/category/life_is_beautiful.html

这种目录结构很熟吧,对 SEO 很友好吧,当然这是后话了,跟我们今天说的不是一回事。这种目录结果,不用我们去给 Web Server 定义一堆路由规则,页面存在即返回,否则返回 404,完全不需要多余的声明逻辑。

基于这种目录结构,我们可以抽象成这样子:

/{page_type}/{page_name}.html

1
/{page_type}/{page_name}.html

其实还可以更简单:

/p/{name}.html

1
/p/{name}.html

从组件化的角度出发,还可以这样子:

/p/{name}/name.js /p/{name}/name.tpl /p/{name}/name.css

1
2
3
/p/{name}/name.js
/p/{name}/name.tpl
/p/{name}/name.css

所以,按照我们简化后的逻辑,我们只需要一个 page.js 这样一个路由加载器,按照我们约定的资源目录结构去加载相应的页面,我们就不需要去干声明路由并且中心化路由这种蠢事了。具体来看代码。咱也懒得去解析了,里面有注释。

压缩、优化

现在我找到了减少请求的方法,我开始寻找各种方法来减重。文件越小,加载速度越快。通常平均的页面大小为1950KB。按照内容分类:

图片:1249KB HTML:58KB CSS:60KB JS:303KB 字体:87KB Flash:67KB 其它:126KB

我使用这些数据作为参考和比较的起点,同时找到我可以用来为网站减负的方法。 我的网站耗费的流量有多少?是一个由Tim Kadlec编写的很棒的工具,可以用来帮助你测试和可视化,来自世界各地的访问在你的网站上消耗的流量。

CPU 内部的处理

移动设备中的 CPU 并不是一个单独的芯片,而是和 GPU 等芯片集成在一起,被称为 SoC(片上系统)。

前面提到了触屏和 CPU 的连接,这个连接和大部分计算机内部的连接一样,都是通过电气信号来进行通信的,也就是电压高低的变化,如下面的时序图:图片 4

在时钟的控制下,这些电流会经过 MOSFET 晶体管,晶体管中包含 N 型半导体和 P 型半导体,通过电压就能控制线路开闭,然后这些 MOSFET 构成了 CMOS,接着再由 CMOS 实现「与」「或」「非」等逻辑电路门,最后由逻辑电路门上就能实现加法、位移等计算,整体如下图所示(来自《计算机体系结构》):图片 5

除了计算,在 CPU 中还需要存储单元来加载和存储数据,这个存储单元一般通过触发器(Flip-flop)来实现,称为寄存器。

以上这些概念都比较抽象,推荐阅读「How to Build an 8-Bit Computer」这篇文章,作者基于晶体管、二极管、电容等原件制作了一个 8 位的计算机,支持简单汇编指令和结果输出,虽然现代 CPU 的实现要比这个复杂得多,但基本原理还是一样的。

另外其实我也是刚开始学习 CPU 芯片的实现,所以就不在这误人子弟了,感兴趣的读者请阅读本节后面推荐的书籍。

挑战三:领域数据中心化

对于单向数据流循环和数据双向绑定谁优谁劣是永远也讨论没结果的问题,要看是什么业务场景什么业务逻辑,如果这个前提没统一好说啥都是白搭。当然,这个挑战的前提是非后台的单页面应用,后台的前端根本就不需要考虑前端内存缓存数据的处理,直接跟接口数据库交互就行了。明确了这个前提,我们接着讨论什么叫领域数据中心化。

前面讨论到两种数据绑定的方式,但是如果频繁跟接口交互:

  • 内存数据销毁了,重新请求数据耗时浪费流量
  • 如果两个接口字段部分不一样但是使用场景一样
  • 多个页面直接有部分的数据相同,但是先来后到导致某些计数字段不一致
  • 多个页面的数据相同,其中某些数据发生用户操作行为导致数据发生变动

因此,我们需要在业务视图逻辑层和数据接口层中间增加一个 store(领域模型),而这个 store 需要有一个统一的 内存缓存 cache,这个 cache 就是中心化的数据缓存。那这个 store 究竟是用来弄啥勒?

图片 6

Store 具有多形态,每个 store 好比某一类物品的仓储(领域,换个词容易理解),如蔬果店 fruit-store, 服装店 clothes-store,蔬果店可以放苹果香蕉黑木耳,服装店可以放背心底裤人字拖。如果品种过于繁多,我们可以把蔬果店精细化运营变成香蕉专卖店,苹果专卖店(!== appstore),甚至是黑木耳专卖店…( _ _)ノ|,蔬果种类不一样,但是也都是称重按斤卖嘛。

var bannerStore = new fruitStore();

var appleStore = new fruitStore();

有了这些仓储之后,我们可以放心的把数据丢给视图逻辑层大胆去用。想修改数据?直接让 store 去改就行了,其他页面的 DOM 文本内容也得修改吧?那是其他页面的业务逻辑做的事,我们把事件抛出去就好了,他们处不处理那是他们的事,咱别瞎操心(业务隔离)。

那么 store 具体弄啥勒?

图片 7

  • 32 个赞位置可点赞或者取消,三个页面的赞数需要同步,按钮点赞与取消的状态也要同步。
  • 条目是否已收藏,取消收藏后 Page B 需要删除数据,Page A C 需要同步状态,如果在 Page C 又有收藏操作,Page B 需要相应增减数据,Page A 状态需要同步。
  • 发评论,Page C 需要更新评论列表和评论数,Page A B 需要更新评论数。如果 Page B 没有被加载过,这时候 Page B 拿到的数据应该是最新的,需要同步给 A C 页面对应的数据进行更新。

所以,store 干的活就是数据状态读写和同步,如果把数据状态的操作放到各个页面自己去处理,页面一旦多了或者复杂起来,就会产生各个页面数据和状态可能不一致,页面之前双向引用(业务耦合严重)。store 还有另一个作用就是数据的输入输出格式化,简单举个栗子:图片 8

  • 任何接口 API 返回的数据,都需要经过 input format 进行统一格式化,然后再写入 cache,因为读取的数据已按照我们约定的规范进行的处理,所以我们使用的时候也不需要理会接口是返回怎样的数据类型。
  • 某些组件需要的数据字段格式可能不同,如果把数据处理放在模板进行处理,会导致模板无法更加简洁通用(业务耦合),所以需要 output format 进行处理。

所以,store 就是扮演着这样的角色——是数据状态读写和同步,以及数据输入输出的格式化处理。

CSS和JavaScript

压缩样式表和JavaScript文件可以明显减少文件大小,我仅在压缩上就从一个文件上节省了56%的空间。

压缩前 压缩后 节省比例
CSS 135KB 104KB 23.0%
JS 16KB 7KB 56.3%

我使用 BEM (代码、元素、修饰符) 方法论编写CSS,这将导致冗长的类名。重构我的一些代码变得更简短(“navigation”为 “nav”, “introduction” 为 “intro”),这让我节省了一些空间,但和我期望的后期压缩相比并不是那么明显。

冗长的类 精简后 节省比例
104KB 97KB 6.7%

我也重新评估了使用jQuery的必要性。对于压缩的135KB的JavaScript,大约96KB是jQuery库——71%之多!这里并没有很多需要依赖于jQuery,所以我花时间重构了代码。我通过剥离jQuery和在Vanilla重写它,去除了122KB,最终压缩后的文件大小减少到13KB。

jQuery Vanilla JS 节省比例
135KB 13KB 122KB (90%)

从那时起,我设法去掉更多空间(压缩后7KB),最后脚本在压缩和gzipped后只有0.365KB。

从 CPU 到操作系统内核

前面说到触屏控制器将电气信号发送到 CPU 对应的引脚上,接着就会触发 CPU 的中断机制,以 Linux 为例,每个外部设备都有一标识符,称为中断请求(IRQ)号,可以通过 /proc/interrupts 文件来查看系统中所有设备的中断请求号,以下是 Nexus 7 (2013) 的部分结果:

shell@flo:/ $ cat /proc/interrupts CPU0 17: 0 GIC dg_timer 294: 1973609 msmgpio elan-ktf3k 314: 679 msmgpio KEY_POWER

1
2
3
4
5
shell@flo:/ $ cat /proc/interrupts
            CPU0
  17:          0       GIC  dg_timer
294:    1973609   msmgpio  elan-ktf3k
314:        679   msmgpio  KEY_POWER

因为 Nexus 7 使用了 ELAN 的触屏控制器,所以结果中的 elan-ktf3k 就是触屏的中断请求信息,其中 294 是中断号,1973609 是触发的次数(手指单击时会产生两次中断,但滑动时会产生上百次中断)。

为了简化这里不考虑优先级问题,以 ARMv7 架构的处理器为例,当中断发生时,CPU 会停下当前运行的程序,保存当前执行状态(如 PC 值),进入 IRQ 状态),然后跳转到对应的中断处理程序执行,这个程序一般由第三方内核驱动来实现,比如前面提到的 Nexus 7 的驱动源码在这里 touchscreen/ektf3k.c。

这个驱动程序将读取 I²C 总线中传来的位置数据,然后通过内核的 input_report_abs 等方法记录触屏按下坐标等信息,最后由内核中的input 子模块将这些信息都写进 /dev/input/event0 这个设备文件中,比如下面展示了一次触摸事件所产生的信息:

130|shell@flo:/ $ getevent -lt /dev/input/event0 [ 414624.658986] EV_ABS ABS_MT_TRACKING_ID 0000835c [ 414624.659017] EV_ABS ABS_MT_TOUCH_MAJOR 0000000b [ 414624.659047] EV_ABS ABS_MT_PRESSURE 0000001d [ 414624.659047] EV_ABS ABS_MT_POSITION_X 000003f0 [ 414624.659078] EV_ABS ABS_MT_POSITION_Y 00000588 [ 414624.659078] EV_SYN SYN_REPORT 00000000 [ 414624.699239] EV_ABS ABS_MT_TRACKING_ID ffffffff [ 414624.699270] EV_SYN SYN_REPORT 00000000

1
2
3
4
5
6
7
8
9
130|shell@flo:/ $ getevent -lt /dev/input/event0
[  414624.658986] EV_ABS       ABS_MT_TRACKING_ID   0000835c
[  414624.659017] EV_ABS       ABS_MT_TOUCH_MAJOR   0000000b
[  414624.659047] EV_ABS       ABS_MT_PRESSURE      0000001d
[  414624.659047] EV_ABS       ABS_MT_POSITION_X    000003f0
[  414624.659078] EV_ABS       ABS_MT_POSITION_Y    00000588
[  414624.659078] EV_SYN       SYN_REPORT           00000000
[  414624.699239] EV_ABS       ABS_MT_TRACKING_ID   ffffffff
[  414624.699270] EV_SYN       SYN_REPORT           00000000

挑战四:Hybrid App 化

现在 Hybrid App 架构应用很火啊 _ (:3」∠)_,不搞一下都不好意思说自己是做 H5的。这里所说的 Hybrid App 可不是那种内置打包的 html 源码那种,而是直接去服务端请求 html 文档那种,可能会使用离线缓存。有的人以为如果要使用 Hybrid 架构,就不能使用 SPA 的方式,其实 Hybrid 架构更应该使用 SPA。

遇到的几个问题,我简单列举一下:

  • 客户端通过 url 传参

    如果通过 http get 请求的 query 参数进行传参,会导致命中不到 html 文档缓存,所以通过 SPA 的 hash query 传参,可以规避这个问题。

  • 与其他 html 页面进行跳转

    这种场景下,进入新页面和返回旧页面导致 webview 会重新加载本地的 html 文档缓存,视觉体验很不爽,即使页面使用了离线缓存,而 SPA 可以规避这个问题。

  • 使用了离线缓存的页面需要支持代码多版本化

    由于采用了非覆盖性资源发布方式,所以需要仍然保留旧的代码一段时间,以防止用户使用旧的 html 文档访问某些按需加载功能或清除了本地缓存数据而拿不到旧版本代码。

  • js 和 css 资源 离线化

    由于离线缓存的资源需要先在 manifest 文件声明,你也不可能总是手动去维护需要引用的 js 和 css 资源,并且那些按需加载的功能也会因此失去按需加载的意义。所以需要将 js 和 css 缓存到 localstorage,直接省去这一步维护操作。至于用户清除 localstorage,参考第三点解决方案。

  • 图标资源离线化

    将图标文件进行 base64 编码后存入 css 文件,方便离线使用。

图片

图片通常占到一个网站的大头。通常网站平均有1249 KB的图片。

我抛弃了图标字体,取而代之的是内联SVG。此外,任何可以矢量化的图片都使用内联SVG替换。我的网站先前版本的一个页面仅仅图标web字体就加载了145KB,同时对于几百个web字体,我只使用了一小部分。相比之下,当前网站的一个页面只加载10KB内联SVG,这可是93%的差异。

SVG sprites看起来很有趣,它可能是我在整个网站使用普通内联SVG图标的一个可行的替代解决方案。

在可能的情况下使用CSS代替图片,现在的CSS能做的已经很多了。然而,浏览器兼容性可能是现代CSS使用的一个问题;因此,充分利用 caniuse.com 和逐步改进。

你也可以通过优化图片来压缩字节。有两种方法来优化图片:

  1. 有损压缩:降低图像的质量
  2. 无损压缩:不影响质量

要同时使用两种方法取得最好的效果,顺序是很重要的。首先使用有损图像压缩方法,比如在不超过必要大小的情况下调整图像大小然后在略低质量且不压缩太多的情况下导出如我通常在82 – 92%下导出JPG图片

图片 9

ImageOptim是OS X下的一个图像优化工具

接下来,使用无损图像优化工具比如 ImageOptim进行处理,从而通过删除不必要的信息,如元数据或颜色配置文件来进一步减少图像文件大小。

从操作系统 GUI 到浏览器

前面提到 Linux 内核已经完成了对硬件的抽象,其它程序只需要通过监听 /dev/input/event0 文件的变化就能知道用户进行了哪些触摸操作,不过如果每个程序都这么做实在太麻烦了,所以在图像操作系统中都会包含 GUI 框架来方便应用程序开发,比如 Linux 下著名的 X。

但 Android 并没有使用 X,而是自己实现了一套 GUI 框架,其中有个 EventHub 的服务会通过 epoll 方式监听 /dev/input/ 目录下的文件,然后将这些信息传递到 Android 的窗口管理服务(WindowManagerService)中,它会根据位置信息来查找相应的 app,然后调用其中的监听函数(如 onTouch 等)。

就这样,我们解答了第一个问题,不过由于时间有限,这里省略了很多细节,想进一步学习的读者推荐阅读以下书籍。

挑战五:性能优化

@前端农民工 在 别处 已经说得很清楚了,直接传送门过去看吧,这里不罗嗦了。

 

1 赞 2 收藏 评论

图片 10

页面渲染

在这一点上,经过工作和汗水得出这些细节,我确信我的 Google PageSpeed Insights 的分数将是90s。

图片 11

在移动平台PSI分数为73/100,而桌面平台上好一点在88/100。它建议我“消除render-blocking的JavaScript和CSS”。

render-blocking文件增加了浏览器显示内容的时间,因为这些文件需要先下载并处理。多个render-blocking文件需要浏览器使用多个线程去获取和处理它们,等待时间进一步增加。

图片 12

优化JavaScript、CSS和web字体的传输,可以提高页面的“第一时间渲染。将这个时间降到最低,理解“关键的渲染路径”很重要,它描述了在当页面的第一个字节被收到,与页面第一次渲染成像素之间发生了什么。

WebPagetest 是用来帮助你配置网站和页面性能最好的可视化工具。

图片 13

About页面在渲染优化前的WebPagetest结果

当最小化第一次渲染时间时,我们更多的关注以尽可能快的速度渲染内容,然后允许额外的“东西”在处理过程中逐步渲染。

扩展学习

  • 《计算机体系结构》
  • 《计算机体系结构:量化研究方法》
  • 《计算机组成与设计:硬件/软件接口》
  • 《编码》
  • 《CPU自制入门》
  • 《操作系统概念》
  • 《ARMv7-AR 体系结构参考手册》
  • 《Linux内核设计与实现》
  • 《精通Linux设备驱动程序开发》

CSS

默认情况下,浏览器将CSS作为渲染阻塞;因此,当它加载时,浏览器暂停渲染,等待CSS已经被下载和处理。外部样式表意味着更多的网络线程,它增加了等待时间,同时大型样式表也会增加等待时间。

我们可以通过在<head>标签内联“关键CSS”来改善页面渲染时间,这样浏览器可以不用再等待下载整个样式表,就可以快速地渲染页面内容,然后通过non-rendering-blocking方式加载完整的样式表。

XHTML

<head> <style> /* inline critical CSS */ </style> </head>

1
2
3
4
5
<head>
  <style>
    /* inline critical CSS */
  </style>
</head>

确定哪些CSS是关键需要(1)查看移动或桌面下页面视口(viewport )大小,(2)识别视口中可见的元素(3)选择这些元素关联的CSS。

这可能有点棘手,特别是手工完成,但是有一些神奇的工具可以帮助加快甚至自动化这个过程。我使用 Filament Group编写的 grunt-criticalcss来帮助我为页面生成关键CSS,然后再手动优化一些CSS(合并重复的媒体查询和删除我认为不必要的CSS)。

图片 14

About页面只加载关键CSS(左侧)和加载整个CSS(右侧)的对比

现在关键CSS已经内联到<head>标签内,我使用loadCSS工具来异步加载样式表的其余部分。

XHTML

<head> <style> /* inline critical CSS */ </style> <script> // inline the loadCSS script function loadCSS( href, before, media, callback ){ ... } // then load your stylesheet loadCSS("/path/to/stylesheet.css"); </script> <noscript> <link href="/path/to/stylesheet.css" rel="stylesheet"> </noscript> </head>

1
2
3
4
5
6
7
8
9
10
11
12
13
14
<head>
  <style>
    /* inline critical CSS */
  </style>
  <script>
   // inline the loadCSS script
   function loadCSS( href, before, media, callback ){ ... }
   // then load your stylesheet
   loadCSS("/path/to/stylesheet.css");
  </script>
  <noscript>
    <link href="/path/to/stylesheet.css" rel="stylesheet">
  </noscript>
</head>

谷歌也给出non-render-blocking加载CSS的 另一个示例 。

第二个问题:浏览器如何向网卡发送数据?

JavaScript

JavaScript也会导致render-blocking因此它的加载也应该优化可以使用以下的方法:

  1. 小的内联脚本。
  2. 在文档底部加载外部脚本。
  3. 使用defer属性推迟执行脚本。
  4. 使用async属性异步加载的脚本。

XHTML

<head> <script> // small inline JS </script> </head> <body> ... <script src="/path/to/independent-script.js" async> <script src="/path/to/parent-script.js" defer> <script src="/path/to/dependent-script.js" defer> </body>

1
2
3
4
5
6
7
8
9
10
11
<head>
  <script>
    // small inline JS
  </script>
</head>
<body>
  ...
  <script src="/path/to/independent-script.js" async>
  <script src="/path/to/parent-script.js" defer>
  <script src="/path/to/dependent-script.js" defer>
</body>

在解析HTML时 defer推迟下载脚本,一旦页面渲染完成执行脚本。defer支持很不错,但据报道存在不一致和不可靠性,所以最好同时使用defer并把脚本放置在文档底部。

在HTML解析和执行时异步下载脚本文件。这允许多个脚本文件并发下载和执行;然而,他们不能保证在一个特定的顺序加载。如果相互依赖可能需要在这些场景下修改任意脚本。

async支持大不如defer,这就是为什么我选择使用loadJS,用来异步加载JS文件的脚本。它支持老式浏览器,同时有一个有用的特性,即根据条件加载脚本。

XHTML

<head> <script> // small inline JS </script> </head> <body> ... <script> // inline loadJS function loadJS( src, cb ){ .. } // then load your JS loadJS("/path/to/script.js"); </script> <script src="/path/to/parent-script.js" defer> <script src="/path/to/dependent-script.js" defer> </body>

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<head>
  <script>
    // small inline JS
  </script>
</head>
<body>
  ...
  <script>
    // inline loadJS
    function loadJS( src, cb ){ .. }
    // then load your JS
    loadJS("/path/to/script.js");
  </script>
  <script src="/path/to/parent-script.js" defer>
  <script src="/path/to/dependent-script.js" defer>
</body>

从浏览器到浏览器内核

前面提到操作系统 GUI 将输入事件传递到了浏览器中,在这过程中,浏览器可能会做一些预处理,比如 Chrome 会根据历史统计来预估所输入字符对应的网站,比如输入了「ba」,根据之前的历史发现 90% 的概率会访问「www.baidu.com 」,因此就会在输入回车前就马上开始建立 TCP 链接甚至渲染了,这里面还有很多其它策略,感兴趣的读者推荐阅读 High Performance Networking in Chrome。

接着是输入 URL 后的「回车」,这时浏览器会对 URL 进行检查,首先判断协议,如果是 http 就按照 Web 来处理,另外还会对这个 URL 进行安全检查,然后直接调用浏览器内核中的对应方法,比如 WebView 中的 loadUrl 方法。

在浏览器内核中会先查看缓存,然后设置 UA 等 HTTP 信息,接着调用不同平台下网络请求的方法。

需要注意浏览器和浏览器内核是不同的概念,浏览器指的是 Chrome、Firefox,而浏览器内核则是 Blink、Gecko,浏览器内核只负责渲染,GUI 及网络连接等跨平台工作则是浏览器实现的

Web字体

Web字体使内容更加清晰和漂亮,但是也对页面渲染产生了负面影响。在加载页面时,特别是移动端的连接,你可能已经注意到文本在一段时间看不见。这被称为 FOIT(不可见文本闪动)。

图片 15

我的网站出现FOIT的样子

当浏览器尝试下载一个web字体,它将隐藏文本一段时间,直到它完成字体下载,才显示文本。在最糟糕的情况下,文本无限期地不可见,使内容完全不能阅读。

我处理FOIT 的方式是逐步加载字体,首先依赖默认和系统字体(例如Helvetica和Georgia)允许快速呈现的内容。Web字体然后使用loadCSS异步加载,同时通过 Font Face Observer库来检测字体何时下载成功。一旦字体下载且可用,一个类被添加到文档中,用于设置页面正确的字体。

JavaScript

<head> <style> body { font-family: Helvetica, Arial, sans-serif; } .fonts-loaded body { font-family: Roboto, Helvetica, Arial, sans-serif; } </style> <script> // inline loadCSS function loadCSS( href, before, media, callback ){ ... } // load webfonts loadCSS("//fonts.googleapis.com/css?family=Roboto:400,500,700"); // inline FontFaceObserver (function(){ ... } // detect loading of fonts var roboto400 = new FontFaceObserver("Roboto", { weight: 400 }); var roboto700 = new FontFaceObserver("Roboto", { weight: 700 }); Promise.all([ roboto400.check(), roboto700.check() ]).then(function() { document.documentElement.className = " fonts-loaded"; }); </script> </head>

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
<head>
  <style>
    body { font-family: Helvetica, Arial, sans-serif; }
    .fonts-loaded body { font-family: Roboto, Helvetica, Arial, sans-serif; }
  </style>
  <script>
    // inline loadCSS
    function loadCSS( href, before, media, callback ){ ... }
    // load webfonts
    loadCSS("//fonts.googleapis.com/css?family=Roboto:400,500,700");
    // inline FontFaceObserver
    (function(){ ... }
    // detect loading of fonts
    var roboto400 = new FontFaceObserver("Roboto", {
      weight: 400
    });
    var roboto700 = new FontFaceObserver("Roboto", {
      weight: 700
    });
 
    Promise.all([
      roboto400.check(),
      roboto700.check()
    ]).then(function() {
      document.documentElement.className = " fonts-loaded";
    });
  </script>
</head>

逐步加载字体将导致FOUT(没有样式的文本闪动)和FOFT(仿文本闪动),这取决于它是如何做的。

图片 16

字体逐步加载,不产生FOIT

然而,好处是内容一直可见,而不会出现看不见的情况。关于如何击败FOIT,我写了一篇的深入文章 使用字体事件加载字体。

HTTP 请求的发送

因为网络的底层实现是和内核相关的,所以这一部分需要针对不同平台进行处理,从应用层角度看主要做两件事情:通过 DNS 查询 IP、通过 Socket 发送数据,接下来就分别介绍这两方面的内容。

其它

其他方法,如启用gzip和缓存、配置SSL和从内容分发网络(CDN)获取资源,可以提高前端性能,但需要一些服务器端支持。基于篇幅所限,我不会深入他们。然而我想强调的是,我推荐使用这些方法,他们将会对你的网站性能有一个全面和积极的影响。

我将提到,因为我的网站的访问量百分比相当一部分来自美国以外,而我的服务器是位于纽约,我于是决定把我的一些资源发布到CDN上。他们部署到一个 Amazon S3  bucket上,绑定到一个CloudFront版本。

DNS 查询

应用程序可以直接调用 Libc 提供的 getaddrinfo() 方法来实现 DNS 查询。

DNS 查询其实是基于 UDP 来实现的,这里我们通过一个具体例子来了解它的查找过程,以下是使用 dig trace fex.baidu.com 命令得到的结果(省略了一些):

; <<>> DiG 9.8.3-P1 <<>> trace fex.baidu.com ;; global options: cmd . 11157 IN NS g.root-servers.net. . 11157 IN NS i.root-servers.net. . 11157 IN NS j.root-servers.net. . 11157 IN NS a.root-servers.net. . 11157 IN NS l.root-servers.net. ;; Received 228 bytes from 8.8.8.8#53(8.8.8.8) in 220 ms com. 172800 IN NS a.gtld-servers.net. com. 172800 IN NS c.gtld-servers.net. com. 172800 IN NS m.gtld-servers.net. com. 172800 IN NS h.gtld-servers.net. com. 172800 IN NS e.gtld-servers.net. ;; Received 503 bytes from 192.36.148.17#53(192.36.148.17) in 185 ms baidu.com. 172800 IN NS dns.baidu.com. baidu.com. 172800 IN NS ns2.baidu.com. baidu.com. 172800 IN NS ns3.baidu.com. baidu.com. 172800 IN NS ns4.baidu.com. baidu.com. 172800 IN NS ns7.baidu.com. ;; Received 201 bytes from 192.48.79.30#53(192.48.79.30) in 1237 ms fex.baidu.com. 7200 IN CNAME fexteam.duapp.com. fexteam.duapp.com. 300 IN CNAME duapp.n.shifen.com. n.shifen.com. 86400 IN NS ns1.n.shifen.com. n.shifen.com. 86400 IN NS ns4.n.shifen.com. n.shifen.com. 86400 IN NS ns2.n.shifen.com. n.shifen.com. 86400 IN NS ns5.n.shifen.com. n.shifen.com. 86400 IN NS ns3.n.shifen.com. ;; Received 258 bytes from 61.135.165.235#53(61.135.165.235) in 2 ms

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
; <<>> DiG 9.8.3-P1 <<>> trace fex.baidu.com
;; global options: cmd
.           11157   IN  NS  g.root-servers.net.
.           11157   IN  NS  i.root-servers.net.
.           11157   IN  NS  j.root-servers.net.
.           11157   IN  NS  a.root-servers.net.
.           11157   IN  NS  l.root-servers.net.
;; Received 228 bytes from 8.8.8.8#53(8.8.8.8) in 220 ms
 
com.            172800  IN  NS  a.gtld-servers.net.
com.            172800  IN  NS  c.gtld-servers.net.
com.            172800  IN  NS  m.gtld-servers.net.
com.            172800  IN  NS  h.gtld-servers.net.
com.            172800  IN  NS  e.gtld-servers.net.
;; Received 503 bytes from 192.36.148.17#53(192.36.148.17) in 185 ms
 
baidu.com.      172800  IN  NS  dns.baidu.com.
baidu.com.      172800  IN  NS  ns2.baidu.com.
baidu.com.      172800  IN  NS  ns3.baidu.com.
baidu.com.      172800  IN  NS  ns4.baidu.com.
baidu.com.      172800  IN  NS  ns7.baidu.com.
;; Received 201 bytes from 192.48.79.30#53(192.48.79.30) in 1237 ms
 
fex.baidu.com.      7200    IN  CNAME   fexteam.duapp.com.
fexteam.duapp.com.  300 IN  CNAME   duapp.n.shifen.com.
n.shifen.com.       86400   IN  NS  ns1.n.shifen.com.
n.shifen.com.       86400   IN  NS  ns4.n.shifen.com.
n.shifen.com.       86400   IN  NS  ns2.n.shifen.com.
n.shifen.com.       86400   IN  NS  ns5.n.shifen.com.
n.shifen.com.       86400   IN  NS  ns3.n.shifen.com.
;; Received 258 bytes from 61.135.165.235#53(61.135.165.235) in 2 ms

可以看到这是一个逐步缩小范围的查找过程,首先由本机所设置的 DNS 服务器(8.8.8.8)向 DNS 根节点查询负责 .com 区域的域务器,然后通过其中一个负责 .com 的服务器查询负责 baidu.com 的服务器,最后由其中一个 baidu.com 的域名服务器查询 fex.baidu.com 域名的地址。

可能你在查询某些域名的时会发现和上面不一样,最底将看到有个奇怪的服务器抢先返回结果。。。

这里为了方便描述,忽略了很多不同的情况,比如 127.0.0.1 其实走的是 loopback,和网卡设备没关系;比如 Chrome 会在浏览器启动的时预先查询 10 个你有可能访问的域名;还有 Hosts 文件、缓存时间 TTL(Time to live)的影响等。

综述

在过去的几个月中我一直在做性能改进,尽管这有很多工作,我确实注意到了差别。我偶尔得到关于我的网站速度的评论,这是性能调整的结果。

我还没有在指标跟踪上做得很好(特别是早期),但让我们看看基于已有数据的一些比较。

平均大小 我的站点 差别
Requests 93 19 -87.6%
Page size 1950KB 524KB -73.1%
HTML 58KB 2.8KB -95.1%
Images 1249KB 66.3 -94.7%
CSS 60KB 14.6KB -75.7%
JS 303KB 6.1KB -98.0%
Fonts 87KB 10.2KB -88.3%

总体上87.5%优于平均水平!不是很坏。现在谷歌PageSpeed也给我的网站一个不错的分数。

图片 17

优化后谷歌PageSpeed的结果

关于WebPagetest的结果**,**我注意到,尽管About页面字节增加了,但开始渲染和加载的时间大大减少。

图片 18

About页面在渲染优化后的WebPagetest结果

性能改进将永远是进行时,在 HTTP/2到来的路上其中一些将改变,之前好用的技术可能不再好用,同时有些可能完全弃用。

我觉得在过去的几个月,我取得了很大的进展,也学到了很多。我的网站在Github上是开源的,所以大家可以随时看一看。我还没有弄明白这一切,但希望我所分享的所做所学,会给你一些见解。如果你有任何问题或想聊一聊,随时骚扰我的Twitter @jonsuh或者给我发 邮件。

通过 Socket 发送数据

有了 IP 地址,就可以通过 Socket API 来发送数据了,这时可以选择 TCP 或 UDP 协议,具体使用方法这里就不介绍了,推荐阅读 Beej’s Guide to Network Programming。

HTTP 常用的是 TCP 协议,由于 TCP 协议的具体细节到处都能看到,所以本文就不介绍了,这里谈一下 TCP 的 Head-of-line blocking 问题:假设客户端的发送了 3 个 TCP 片段(segments),编号分别是 1、2、3,如果编号为 1 的包传输时丢了,即便编号 2 和 3 已经到达也只能等待,因为 TCP 协议需要保证顺序,这个问题在 HTTP pipelining 下更严重,因为 HTTP pipelining 可以让多个 HTTP 请求通过一个 TCP 发送,比如发送两张图片,可能第二张图片的数据已经全收到了,但还得等第一张图片的数据传到。

为了解决 TCP 协议的性能问题,Chrome 团队去年提出了 QUIC 协议,它是基于 UDP 实现的可靠传输,比起 TCP,它能减少很多来回(round trip)时间,还有前向纠错码(Forward Error Correction)等功能。目前 Google Plus、 Gmail、Google Search、blogspot、Youtube 等几乎大部分 Google 产品都在使用 QUIC,可以通过 chrome://net-internals/#spdy 页面来发现。

虽然目前除了 Google 还没人用 QUIC,但我觉得挺有前景的,因为优化 TCP 需要升级系统内核(比如 Fast Open)。

浏览器对同一个域名有连接数限制,大部分是 6,我以前认为将这个连接数改大后会提升性能,但实际上并不是这样的,Chrome 团队有做过实验,发现从 6 改成 10 后性能反而下降了,造成这个现象的因素有很多,如建立连接的开销、拥塞控制等问题,而像 SPDY、HTTP 2.0 协议尽管只使用一个 TCP 连接来传输数据,但性能反而更好,而且还能实现请求优先级。

另外,因为 HTTP 请求是纯文本格式的,所以在 TCP 的数据段中可以直接分析 HTTP 的文本,如果发现。。。

资源

这里是丰富的有用资源,让你深入了解网站性能。

  • 深入谷歌PageSpeed
  • SpeedCurve
  • WebPagetest
  • 我的网站耗费的流量有多少?
  • 网页设计师和前端开发人员需要关注的前端性能
  • 如何让RWD网站的速度飙起来
  • 提升Smashing Magazine的性能:案例学习
  • 网站更庞大并不意味着更多的等待时间
  • 优化性能
  • RWD 膨胀 第一部分 和 第二部分
  • 谷歌PageSpeed模块
  • 负责任的社交分享链接
  • 首次访问的内联关键CSS
  • async 和 defer属性的比较
  • 使用字体事件加载字体
  • 使用字体事件再次加载字体
  • 关于字体加载后续——仿文本闪动
  • 播客——通往高性能网站

    1 赞 9 收藏 1 评论

Socket 在内核中的实现

前面说到浏览器的跨平台库通过调用 Socket API 来发送数据,那么 Socket API 是如何实现的呢?

以 Linux 为例,它的实现在这里 socket.c,目前我还不太了解,推荐读者看看 Linux kernel map,它标注出了关键路径的函数,方便学习从协议栈到网卡驱动的实现。

关于作者:cucr

图片 19

新浪微博:@hop_ping 个人主页 · 我的文章 · 17

图片 20

底层网络协议的具体例子

接下来如果继续介绍 IP 协议和 MAC 协议可能很多读者会晕,所以本节将使用 Wireshark 来通过具体例子讲解,以下是我请求百度首页时抓取到的网络数据:图片 21

最底下是实际的二进制数据,中间是解析出来的各个字段值,可以看到其中最底部为 HTTP 协议(Hypertext Transfer Protocol),在 HTTP 之前有 54 字节(0x36),这就是底层网络协议所带来的开销,我们接下来对这些协议进行分析。

在 HTTP 之上是 TCP 协议(Transmission Control Protocol),它的具体内容如下图所示:图片 22

通过底部的二进制数据,可以看到 TCP 协议是加在 HTTP 文本前面的,它有 20 个字节,其中定义了本地端口(Source port)和目标端口(Destination port)、顺序序号(Sequence Number)、窗口长度等信息,以下是 TCP 协议各个部分数据的完整介绍:

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | Source Port | Destination Port | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | Sequence Number | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | Acknowledgment Number | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | Data | |U|A|E|R|S|F| | | Offset| Reserved |R|C|O|S|Y|I| Window | | | |G|K|L|T|N|N| | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | Checksum | Urgent Pointer | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | Options | Padding | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | data | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
|          Source Port          |       Destination Port        |
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
|                        Sequence Number                        |
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
|                    Acknowledgment Number                      |
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
|  Data |           |U|A|E|R|S|F|                               |
| Offset| Reserved  |R|C|O|S|Y|I|            Window             |
|       |           |G|K|L|T|N|N|                               |
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
|           Checksum            |         Urgent Pointer        |
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
|                    Options                    |    Padding    |
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
|                             data                              |
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

具体各个字段的作用这里就不介绍了,感兴趣的读者可以阅读 RFC 793,并结合抓包分析来理解。

需要注意的是,在 TCP 协议中并没有 IP 地址信息,因为这是在上一层的 IP 协议中定义的,如下图所示:图片 23

IP 协议同样是在 TCP 前面的,它也有 20 字节,在这里指明了版本号(Version)为 4,源(Source) IP 为 192.168.1.106,目标(Destination) IP 为 119.75.217.56,因此 IP 协议最重要的作用就是确定 IP 地址。

因为 IP 协议中可以查看到目标 IP 地址,所以如果发现某些特定的 IP 地址,某些路由器就会。。。

但是,光靠 IP 地址是无法进行通信的,因为 IP 地址并不和某台设备绑定,比如你的笔记本的 IP 在家中是 192.168.1.1,但到公司就变成172.22.22.22 了,所以在底层通信时需要使用一个固定的地址,这就是 MAC(media access control) 地址,每个网卡出厂时的 MAC 地址都是固定且唯一的。

因此再往上就是 MAC 协议,它有 14 字节,如下所示:图片 24

当一台电脑加入网络时,需要通过 ARP 协议告诉其它网络设备它的 IP 及对应的 MAC 地址是什么,这样其它设备就能通过 IP 地址来查找对应的设备了。

最顶上的 Frame 是代表 Wireshark 的抓包序号,并不是网络协议

就这样,我们解答了第二个问题,不过其实这里面还有很多很多细节没介绍,建议大家通过下面的书籍进一步学习。

扩展学习

  • 《计算机网络:自顶向下方法与Internet特色》
  • 《计算机网络》
  • 《Web性能权威指南》

第三个问题:数据如何从本机网卡发送到服务器?

本文由网上十大正规赌博平台发布于正规赌博十大app排名,转载请注明出处:快速提升前端性能,到页面加载完成的过程中都

关键词: bbin游戏平台

上一篇:浏览器缓存机制,理解SVG坐标系统和变换

下一篇:没有了