12 月 28 日消息,今日早间,阿里巴巴集团 CPO 童文红在内部论坛宣布,将取消强制“361”考核制度,不再强制直属领导给 10% 员工 3 分-3.25 分的绩效评级。阿里巴巴集团员工向凤凰网科技证实了该消息。   阿里巴巴的绩效考核制度,将绩效评分标准整体按照“361”比重分配:3.75-5 分的员工占 30%,3.5-3.75 分的员工占 60%,3 分-3.25 分的员工占 10%。如果员工年终绩效为 3.25 分或以下,则会被取消年终奖和晋升机会,连续 2 年绩效评分低于 3.25 就会面临被辞退。   “361&r...... Last article READ

网络比15年前更慢错误更多?开发者加载了100万个网站实测

  目前业内有个大部分人都赞同的观点:网络相比较 15 年前速度更慢,而且错误更多。由于不断增加的 JavaScript、框架、Webfonts 和 polyfills,已经抵消了更快的计算性能、网络和协议带来的优势。那么实际情况真的如此吗?

  开发者 Lars Eidnes 加载了全球排行前 100 万的网站,追踪每个量化指标,并记录了每个错误、关注每个请求的 URL。他创建首个将网络性能、错误和库联系起来的数据库。而在本文中,他对这些数据进行了分析,并帮助站长找到创建高性能网站的合适方法。

  为什么要加载 100 万个网页?

  正如文章开头所提及的,当前网络真的要比 15 年前更慢了吗? 开发者 Lars Eidnes 试图找到 2020 年网络速度变慢以及出现崩溃的主要原因。

  这个计划非常简单:编写一个网页浏览器的脚本,让它加载渲染前 100 万个域名的主页面,然后按照目前可以量化的指标进行追踪:包括渲染时间、请求次数、,重绘,JavaScript 错误, 使用的库等等。

  对这些数据进行分析之后,我们能够更深入的了解不同因素之间的影响。例如,哪些因素导致页面加载时间过长?哪些库和长时间的可交互时间(Time to Interactive,简称 TTI)有关?最常见的错误是什么?是什么原因导致的?

  总体情况

  开发者使用 Puppeteer 编写了一个 Chrome 脚本,启动了 200 个 EC2 实例,并在周末的时候加载渲染 100 万个网站。整体数据如下:

  HTTP 2 现在比 HTTP 1.1 更常见,但 HTTP 3 仍然很少见。(注意:我们把任何使用 QUIC 协议的东西都算作 HTTP 3,即使 Chrome 有时会报告为 HTTP 2 + QUIC)。这是对根文件而言,对于链接资源,协议号看起来有些不同。

  对于链接资源,HTTP 3 的普及率大约是 HTML 文档情况下的 100 倍。这怎么可能是真的呢?因为所有的网站都在链接同样的东西。

  在很大一部分网站上都有少量的脚本链接。这意味着我们可以期待这些资源在缓存中,对吗?不再是了。从 Chrome 86 开始,从不同域请求的资源将不共享缓存。火狐正在计划实现同样的功能。Safari 多年来一直这样分割缓存。

  那么,是什么让网络变得缓慢?预测交互时间(Predicting time-to-interactive)

  鉴于这个网页的数据集和它们的加载时间指标,如果能了解一些关于是什么让网页变慢的信息就更好了。对此,开发者重点研究了 dominteractive 指标,也就是文档成为用户互动之前的时间。最简单的做法是,我们只需要看看每个指标与 dominteractive 的相关性。

  基本上每个指标都与 dominteractive 呈现正相关的关系,除了 0.x 和 1.x 版本之外。这些指标中的许多指标之间也是正相关的。我们需要一个更复杂的方法来了解导致高交互时间的各个因素。

  其中有些指标是时间,以毫秒为单位。我们可以看一下他们的框图,了解浏览器的时间都花在哪里。导致长互动时间的各个因素的一种方法是做一个线性回归,我们从其他指标预测 dominteractive。

  也就是说,我们给每个指标分配一个权重,将一个页面的 dominteractive 时间建模为其他指标的加权和,再加上一些常数。优化算法设置权重,使整个数据集的预测误差最小化。通过回归发现的权重大小,可以告诉我们每个指标对页面加载缓慢的影响有多大?

  开发者从回归算法中排除时间指标。如果我们花了 500ms 建立连接,就会给 dominteractive 增加 500ms,但这并不是一个特别有趣的见解。时间指标从根本上说是结果。我们希望了解是什么原因导致了它们。

  括号中的数字是优化算法学习的回归系数。您可以将这些数字解释为具有毫秒的单位。虽然确切的数字应该带着盐分(见下面的注释),但看到分配给每个特征的比例是很有趣的。

  例如,该模型预测,每当传递主文档所需的重定向时,会有 354ms 的减速。每当主 HTML 文档通过 HTTP2 或更高版本交付时,模型预测的交互时间会降低 477ms。对于文档触发的每一个请求,它预测了额外的 16ms。

  在解释回归系数时,我们需要记住,我们是在现实的简化模型上操作。事实上,交互时间并不是由这些输入指标的加权和决定的。显然,模型没有机会发现一些因果因素。混淆变量显然是一个问题。

  举个例子,如果用 HTTP2 加载主文档与通过 HTTP2 加载其他请求是相关的,那么模型会把这个优势渲染到 main_doc_is_http2_or_greater 的权重中,即使速度的提升来自主文档以外的请求。当我们将模型所说的内容映射到关于现实的结论时,我们需要谨慎。

  不同 HTTP 协议版本对 dominteractive 的影响有多大?

  这里有一个有趣的图,dominteractive 按用于传递 HTML 主页面的 HTTP 协议版本来划分。有极少数网站仍然通过 HTTP 0.9 和 1.0 交付。而这些网站恰好都很快。似乎我们无法脱离这样一个事实:协议变得更快的效果是,程序员会很乐意通过向浏览器交付更多的东西来消耗这种加速。

  这是对用于交付 HTML 根基页面的协议版本而言。如果我们看一下协议对该文档中链接的资源的影响呢?如果我们按协议版本对请求次数进行回归,就会得到以下结果。

  如果我们相信这一点,我们就会得出这样的结论:将请求的资源从 HTTP 1.1 移到 2 上,速度会加快 1.8 倍,而从 HTTP 2 移到 3 上则会慢 0.6 倍。HTTP 3 真的是一个较慢的协议吗?不是:更可能的解释是 HTTP 3 很少见,通过 HTTP 3 发送的少数资源(如 Google Analytics)是对 dominteractive 影响大于平均水平的东西。

  不同类型的内容对 dominteractive 的影响有多大?

  我们从传输的字节数来预测 dominteractive 的时间,按照传输的数据类型来划分。在这里,请求是按照发起请求的内容来划分的。显然,并不是所有的请求都是平等的。由链接元素触发的请求(即 CSS、favicons)和由 CSS 触发的请求(即字体、更多 CSS)以及脚本和 iframe 会大大减慢速度。

  在 XHR 和 fetch 上做请求会预示着比基线 dominteractive 时间更快(可能是因为这些请求几乎都是异步的)。CSS 和脚本经常以渲染阻塞的方式加载,所以发现它们与较慢的交互时间相关联也就不足为奇了。视频的成本相对较低。

  经验教训

  我们在这里并没有发现任何新的优化技巧,但分析确实让人了解到各种优化所能带来的影响情况。以下说法似乎有很好的经验支持。

● 尽可能少地提出请求请求的数量比传输的千字节数更重要。

● 对于你必须要做的请求,如果可以的话,通过 HTTP2 或更高版本来做。

● 尽量避免渲染阻塞请求,尽可能选择异步加载。

12月23日下午,虚拟现实产业研讨会暨山东省虚拟现实制造业创新中心专家委员会成立仪式在青岛举行。会议邀请了来自北京航空航天大学、北京师范大学、山东大学、中国海洋大学、中国科学院软件研究所等虚拟现实相关院校和科研院所的多名业内知名专家,以及青岛市和崂山区工信局等政府主管部门领导,针对目前虚拟现实产业发展及创新中心建设方案进行研讨并提出改进措施和实施建议,中国工程院院士赵沁平参与了本次会议并致辞。(企业供图,下同)赵沁平院士在致辞中提到,虚拟现实是新兴技术,整个产业的形成和发展,需要在技术、人才、企业、资本、政府政策等多个方面进行投入,希望山东省虚拟现实制造业创新中心的建立,可以打通人才链、创新链......Next article READ