xml地图|网站地图|网站标签 [设为首页] [加入收藏]
Web品质优化类别,谈谈前后端的分工同盟
分类:web前端

Web性能优化系列(2):剖析页面绘制时间

2015/04/15 · CSS, HTML5, JavaScript · 性能优化

本文由 伯乐在线 - 刘健超-J.c 翻译,sunbiaobiao 校稿。未经许可,禁止转载!
英文出处:www.deanhume.com。欢迎加入翻译组。

最近,我参加了在伦敦举办的Facebook移动开发者大会。在那天期间,有很多的交谈,但真正让我关注的是一场关于性能的,名为“让m.facebook.com更快”的交流会,它的主题是关于Facebook如何不断努力改善网页性能和从中汲取的经验。

Facebook开发团队是使用Chrome Cannry来测试网页CSS性能的。Google Chrome Canary拥有Chrome的最新特性,并允许试用一些即将成为Chrome标准版本的,可行的最新特性。考虑到Chrome Canary作为一个为开发者和尝鲜者专门设计的“预览版”,所以有时候会因Chrome开发团队的快速迭代而导致一些B UG。尽管如此,它仍然有一些很棒的开发者工具帮助你测试网页性能

图片 1

在这篇文章里,我展示如何使用Chrome Canary的开发者工具去定位你的CSS中的一部分,这部分CSS可能会导致页面滚动缓慢和影响页面的绘制时间。当浏览器加载和绘制页面时,为了“绘制”并让内容显示在屏幕上,需要遍历所有可见元素。由于这依赖于布局和复杂的CSS,你可能会发现绘制时间会很长。这会导致网页看起来忽动忽停和响应较慢。这种缓慢滚动也称为jank(jank是Android系统的一个专业术语,指的是屏幕上流畅动态画面中断的卡顿现象)。在移动设备上滚动页面时,浏览器会使劲地绘制复杂的CSS,这时这种情况更加明显。

即使页面的加载时间十分快,也仍然值得去研究页面的绘制时间。不同设备对CSS属性有着不一样的反应,但无论如何,能提高性能总是一件很好的事。为了进行测试,首先得去Google Chrome网站下载Chrome Canary。一旦安装完成,就可以打开你想测试的网页。HTML5 Rocks网站里有一个很好的案例网站,我们使用它来证明高耗能CSS属性的操作,会增加页面的绘制时间。

图片 2

一旦你打开到这个网页,按下F12,会弹出Chrome的开发者工具。然后在开发者工具的底部右侧点击设置按钮,开启测试页面渲染性能的设置。

图片 3

点击后会显示一个允许你更改设置的控制板。

图片 4

因为我们要测试页面的渲染性能,所以选择“Enable continuous page repainting(页面持续重新绘制)“和 “Show FPS meter(显示FPS仪表)”**。如果你关闭设置面板,查看你的网页,你应该会看到下面的图片在页面右上角。

图片 5

该表显示以毫秒为单位的当前页面绘制所需时间,而右侧显示了当前图表的最小与最大值。另外,也显示了最近80帧的树状图。这个图表的强大之处是它不断试图重新绘制页面,使得页面好像是第一次加载。这允许你精确定位因CSS影响的绘制问题,而不用每次重新加载页面。无论你的改变是否产生影响,树状图都会持续监测。

如果我们详细查看这个页面的HTML和CSS,你会看到其中一个div添加了一些CSS效果。

图片 6

这个div有border-radius(圆角)和投影属性。当移除box-shadow属性,再观察FPS meter在绘制时间的变化。

图片 7

哇!正如你从图表可看出,页面绘制时间有一个令人关注的变化。通过简单地将border-radius属性移除,就可以证明这个改变能让页面的绘制时间显著减少。当你更新或改变CSS属性时,这个图表就立即下降。在同一个元素上同时使用box-shadowborder-radius,会导致非常重的绘制负担,这是因为浏览器不能为之做出优化。如果有一个元素需要频繁的重复绘制,你应该在建立网页时时刻记住这点。

这是一个很好的,在Google IO 网站上的视频,它更深入地阐述绘制时间,并介绍一些减少网页“jank(卡顿)”的技巧。

想更进一步学习绘制时间的优化,看看这些链接。

祝测试愉快!

打赏支持我翻译更多好文章,谢谢!

打赏译者

HTML5 web通知API介绍

2015/04/17 · HTML5 · 2 评论 · web通知

本文由 伯乐在线 - ElvisKang 翻译,周进林 校稿。未经许可,禁止转载!
英文出处:www.sevensignature.com。欢迎加入翻译组。

图片 8

在使用网页版Gmail的时候,每当收到新邮件,屏幕的右下方都会弹出相应的提示框。借助HTML5提供的Notification API,我们也可以轻松实现这样的功能。

谈谈前后端的分工协作

2015/05/15 · HTML5 · 1 评论 · Web开发

原文出处: 小胡子哥的博客(@Barret李靖)   

前后端分工协作是一个老生常谈的大话题,很多公司都在尝试用工程化的方式去提升前后端之间交流的效率,降低沟通成本,并且也开发了大量的工具。但是几乎没有一种方式是令双方都很满意的。事实上,也不可能让所有人都满意。根本原因还是前后端之间的交集不够大,交流的核心往往只限于接口及接口往外扩散的一部分。这也是为什么很多公司在招聘的时候希望前端人员熟练掌握一门后台语言,后端同学了解前端的相关知识。

打赏支持我翻译更多好文章,谢谢!

任选一种支付方式

图片 9 图片 10

赞 2 收藏 评论

确保浏览器支持

如果你在特定版本的浏览器上进行开发,那么我建议你先到 caniuse 查看浏览器对Notification API的支持情况,避免你将宝贵时间浪费在了一个无法使用的API上。

一、开发流程

前端切完图,处理好接口信息,接着就是把静态demo交给后台去拼接,这是一般的流程。这种流程存在很多的缺陷。

  • 后端同学对文件进行拆分拼接的时候,由于对前端知识不熟悉,可能会搞出一堆bug,到最后又需要前端同学帮助分析原因,而前端同学又不是特别了解后端使用的模板,造成尴尬的局面。
  • 如果前端没有使用统一化的文件夹结构,并且静态资源(如图片,css,js等)没有剥离出来放到 CDN,而是使用相对路径去引用,当后端同学需要对静态资源作相关配置时,又得修改各个link,script标签的src属性,容易出错。
  • 接口问题
    1. 后端数据没有准备好,前端需要自己模拟一套,成本高,如果后期接口有改变,自己模拟的那套数据又不行了。
    2. 后端数据已经开发好,接口也准备好了,本地需要代理线上数据进行测试。这里有两个费神的地方,一是需要代理,否则可能跨域,二是接口信息如果改动,后期接你项目的人需要改你的代码,麻烦。
  • 不方便控制输出。为了让首屏加载速度快一点,我们期望后端先吐出一点数据,剩下的才去 ajax 渲染,但让后端吐出多少数据,我们不好控。

当然,存在的问题远不止上面枚举的这些,这种传统的方式实在是不酷(Kimi 附身^_^)。还有一种开发流程,SPA(single page application),前后端职责相当清晰,后端给我接口,我全部用 ajax 异步请求,这种方式,在现代浏览器中可以使用 PJAX 稍微提高体验,Facebook 早在三四年前对这种 SPA 的模式提出了一套解决方案,quickling+bigpipe,解决了 SEO 以及数据吐出过慢的问题。他的缺点也是十分明显的:

  • 页面太重,前端渲染工作量也大
  • 首屏还是慢
  • 前后端模板复用不了
  • SEO 依然很狗血(quickling 架构成本高)
  • history 管理麻烦

问题多的已经是无力吐槽了,当然他依然有自己的优势,咱们也不能一票否决。

针对上面看到的问题,现在也有一些团队在尝试前后端之间加一个中间层(比如淘宝UED的 MidWay )。这个中间层由前端来控制。

JavaScript

+----------------+ | F2E | +---↑--------↑---+ | | +---↓--------↓---+ | Middle | +---↑--------↑---+ | | +---↓--------↓---+ | R2E | +----------------+

1
2
3
4
5
6
7
8
9
10
11
    +----------------+
    |       F2E      |
    +---↑--------↑---+
        |        |
    +---↓--------↓---+
    |     Middle     |
    +---↑--------↑---+
        |        |  
    +---↓--------↓---+
    |       R2E      |
    +----------------+

中间层的作用就是为了更好的控制数据的输出,如果用MVC模型去分析这个接口,R2E(后端)只负责 M(数据) 这部分,Middle(中间层)处理数据的呈现(包括 V 和 C)。淘宝UED有很多类似的文章,这里不赘述。

本文由澳门新葡亰手机版发布于web前端,转载请注明出处:Web品质优化类别,谈谈前后端的分工同盟

上一篇:没有了 下一篇:跨域访问和防盗链基本原理,别人家的面试题
猜你喜欢
热门排行
精彩图文