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

[codde]

出自《高性能网站建设指南》，真实开发是这种情况吗？我是写后端的，前端了解不多

[o0]

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

[murmur]

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

[learningman]

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

[kobezone]

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

[codde]

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

[shakoon]

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

[realkaiway]

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

[ClericPy]

比如说...?

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

这样吗

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

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

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

[LLaMA2]

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

[az22c]

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

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

[az22c]

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

[codde]

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

[codde]

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

[night98]

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

[murmur]

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

[karott7]

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

[Cbdy]

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

[shyangs]

這本書出版年代 2007 年

IE6 市場優勢年代. IE 7 剛發佈沒多久. Firefox 則是 1.5 或 2.0 版本.


在現在來說, 如果你老闆喜歡統計式報表. 動不動十萬筆百萬筆資料的實時統計. 那後端絕對比較慢.

[rabbbit]

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

[rabbbit]

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