如果将后端响应时间缩短一半，则整体响应时间只能减少 5%-10% 而关注前端，同样缩短一半，则整体响应时间可减少 40%-45%

提供给 C 端的网页通常是通过后端的模板引擎生成的 HTML 页面，这时后台的响应速度就很重要，因为先由后台响应 HTML 结果，返回到浏览器后再去加载静态资源和接口等数据；
而现在很多后台管理系统等单页面站点，则是先加载 HTML 页面（和静态资源），然后请求后台数据，可能就需要先重点关注一下前端的东西。

吹牛逼吧，首屏出来了然后模块和数据都在转圈圈，这也叫响应时间？？？

后端处理时间一般不是大头，数据在路上的时间才是

这个要看情况的 真实的开发一般是接口性能不足 前端一般响应很快的 然后是前台配合后台 各种调用 分批调 多次调用等等 复杂的组装都放在前台了

@o0 目前前后端分离的形式应该都是先加载 HTML 页面（和静态资源），然后在请求后端数据吧

前端的性能往往还受限于客户端环境的具体情况，后端的性能也可能受限于数据库的查询效率，所以还是得具体问题具体分析，不能一概而论

自己真实的业务，先抽几个代表页面（对，就是你认为反应比较慢的）跑一下 performance ，分析一下就知道是前后端哪个家伙的问题。

比如说...?

后端 100ms 变成 50ms
前端 1000ms 变成 500ms

这样吗

cdn 下载一大堆 js 或者 webpack 啥的算前算后, 毕竟性能瓶颈很多时间在网络 IO 上

页面渲染构建 DOM 应该是前端, 写的好和写的差性能还真的可以差距很大

然而大多数时间其实还是理论值. 如果 Page.loadEventFired 事件发生时算响应结束的话, 算了编不下去了

做后端的时候始终给每个控制器打上时间戳，从参数进入后结果吐出的时间记录好，别人说慢，马上打开网页请求一下，记录下浏览器中使用的时间和你服务器上日志里的时间差，就知道谁的问题了，有问题的时候正面面对，又不是生与死，没有什么是协调不了的。

说明浏览器确实吃内存和 cpu 啊，手动狗头

浏览器厂商能不负有责任？

还有老板的欲望是无限的，一个 app 几十几百个页面要协调好，能不卡吗

刚看到这本书英文名是 High Performance Web Sites: Essential Knowledge for Front-End Engineers 高性能网站。前端工程师的基本知识。

我开发时间比较短，平时我的开发基本上就是后端查询接口比较慢，基本没怎么见过前端渲染要渲染很久的，所以看到这个比较有疑惑。

体感问题，而且接口 api 通常不会返回很多内容，前端随便一个 css ，js ，img 优化一下效果提升都挺大的

@codde 举个例子，50*10 的 element ui 表格，IE 下渲染会卡死

从标题来看，侧重用户访问体验，如果是这样，那优化前端确实很重要，比如一个页面有很多图片，比如想 B 站这样的长列表页面优化好了之后体验提升是很大的
一般情况下先升级到 H2 ，js/css/img/font 等静态资源设置 Cache-Control 响应头就能提升很大的用户体验（没设置默认是缓存一小时

看一下出版日期吧，你这个书已经过时了

本出版年代 2007 年

IE6 市年代. IE 7 多久. Firefox 是 1.5 或 2.0 版本.


在在, 如果你老喜式表. 不十百料的. 那後端比慢.

我写过一个表格，业务要求 1 万条的树状节点直接全部加载展开显示。
（说穿了还是业务设计不合理，这么多表格谁看的过来？）

然后有些处理后端就不给你作（例如改个时间格式），让前端自己处理。你说这 1 万条遍历一遍跑下来是前端快还是后端快？

我没看这本书，我是在豆瓣搜了这本书，然后在原文摘录里看到这段话，觉得疑惑，所以复制过来问一下大家。内容的确是比较老了。

@rabbbit #20 前端跑用的是客户端的资源，现在客户端性能越来越高，一个请求数据量有限，慢也慢的有限，后端可用的是自己的资源，100 个用户同时用时间就 x100 ，10000 个用户同时用就 x10000 ，除非不差钱可以无脑堆机器，不然不是重要的东西真的没必要放后端。

有可能有这种情况。前端做得好，后端再怎么拉，网站响应时间也能保持不错的样子。因为前端只要转圈圈告诉用户系统在处理，就是有响应。