如果将后端响应时间缩短一半，则整体响应时间只能减少 5%-10% 而关注前端，同样缩短一半，则整体响应时间可减少 40%-45%
codde · 2022-04-12 11:17:12 +08:00 · 3184 次点击这是一个创建于 960 天前的主题，其中的信息可能已经有所发展或是发生改变。
出自《高性能网站建设指南》，真实开发是这种情况吗？我是写后端的，前端了解不多
 |
1
o0 2022-04-12 11:22:44 +08:00
提供给 C 端的网页通常是通过后端的模板引擎生成的 HTML 页面，这时后台的响应速度就很重要，因为先由后台响应 HTML 结果，返回到浏览器后再去加载静态资源和接口等数据；
而现在很多后台管理系统等单页面站点，则是先加载 HTML 页面（和静态资源），然后请求后台数据，可能就需要先重点关注一下前端的东西。 |
 |
2
murmur 2022-04-12 11:26:04 +08:00
吹牛逼吧，首屏出来了然后模块和数据都在转圈圈，这也叫响应时间？？？
|
 |
3
learningman 2022-04-12 11:26:30 +08:00
后端处理时间一般不是大头，数据在路上的时间才是
|
 |
4
kobezone 2022-04-12 11:26:36 +08:00 via Android
这个要看情况的 真实的开发一般是接口性能不足 前端一般响应很快的 然后是前台配合后台 各种调用 分批调 多次调用等等 复杂的组装都放在前台了
|
 |
6
shakoon 2022-04-12 11:31:26 +08:00
前端的性能往往还受限于客户端环境的具体情况，后端的性能也可能受限于数据库的查询效率，所以还是得具体问题具体分析，不能一概而论
|
 |
7
realkaiway 2022-04-12 11:36:48 +08:00 via iPhone
自己真实的业务，先抽几个代表页面（对，就是你认为反应比较慢的）跑一下 performance ，分析一下就知道是前后端哪个家伙的问题。
|
 |
8
ClericPy 2022-04-12 11:38:04 +08:00
比如说...?
后端 100ms 变成 50ms 前端 1000ms 变成 500ms 这样吗 cdn 下载一大堆 js 或者 webpack 啥的算前算后, 毕竟性能瓶颈很多时间在网络 IO 上 页面渲染构建 DOM 应该是前端, 写的好和写的差性能还真的可以差距很大 然而大多数时间其实还是理论值. 如果 Page.loadEventFired 事件发生时算响应结束的话, 算了编不下去了 |
 |
9
LLaMA2 2022-04-12 11:40:42 +08:00
做后端的时候始终给每个控制器打上时间戳，从参数进入后结果吐出的时间记录好，别人说慢，马上打开网页请求一下，记录下浏览器中使用的时间和你服务器上日志里的时间差，就知道谁的问题了，有问题的时候正面面对，又不是生与死，没有什么是协调不了的。
|
 |
10
az22c 2022-04-12 11:44:15 +08:00 via Android
说明浏览器确实吃内存和 cpu 啊，手动狗头
浏览器厂商能不负有责任？ |
|
11
az22c 2022-04-12 11:46:15 +08:00 via Android
还有老板的欲望是无限的，一个 app 几十几百个页面要协调好，能不卡吗
|
 |
12
codde OP 刚看到这本书英文名是 High Performance Web Sites: Essential Knowledge for Front-End Engineers 高性能网站。前端工程师的基本知识。
|
|
13
codde OP 我开发时间比较短，平时我的开发基本上就是后端查询接口比较慢，基本没怎么见过前端渲染要渲染很久的，所以看到这个比较有疑惑。
|
 |
14
night98 2022-04-12 12:27:01 +08:00
体感问题，而且接口 api 通常不会返回很多内容，前端随便一个 css ，js ，img 优化一下效果提升都挺大的
|
 |
16
karott7 2022-04-12 13:33:56 +08:00
从标题来看，侧重用户访问体验，如果是这样，那优化前端确实很重要，比如一个页面有很多图片，比如想 B 站这样的长列表页面优化好了之后体验提升是很大的
一般情况下先升级到 H2 ，js/css/img/font 等静态资源设置 Cache-Control 响应头就能提升很大的用户体验（没设置默认是缓存一小时 |
 |
17
Cbdy 2022-04-12 13:36:32 +08:00 via Android
看一下出版日期吧，你这个书已经过时了
|
 |
18
shyangs 2022-04-12 13:41:45 +08:00
這本書出版年代 2007 年
IE6 市場優勢年代. IE 7 剛發佈沒多久. Firefox 則是 1.5 或 2.0 版本. 在現在來說, 如果你老闆喜歡統計式報表. 動不動十萬筆百萬筆資料的實時統計. 那後端絕對比較慢. |
 |
19
rabbbit 2022-04-12 13:45:35 +08:00
我写过一个表格，业务要求 1 万条的树状节点直接全部加载展开显示。
（说穿了还是业务设计不合理，这么多表格谁看的过来？） |
|
20
rabbbit 2022-04-12 13:49:19 +08:00
然后有些处理后端就不给你作（例如改个时间格式），让前端自己处理。你说这 1 万条遍历一遍跑下来是前端快还是后端快？
|
 |
21
ChefIsAwesome 2022-04-12 14:06:43 +08:00
书太老了。
你这问题问的也莫名其妙。得出这结论之前，作者说了前端的性能瓶颈在哪，为什么优化那些地方性能提升大。你应该问那些瓶颈现在还有没有，而不是问这结论现在还对不对。 而且我记得那书里应该也说了，性能跟着时代进步，几年前的最佳实践几年后不一定就适用。 |
|
22
codde OP 我没看这本书，我是在豆瓣搜了这本书，然后在原文摘录里看到这段话，觉得疑惑，所以复制过来问一下大家。内容的确是比较老了。
|
 |
23
newtype0092 2022-04-12 14:46:21 +08:00  1
@rabbbit #20 前端跑用的是客户端的资源，现在客户端性能越来越高，一个请求数据量有限，慢也慢的有限，后端可用的是自己的资源，100 个用户同时用时间就 x100 ，10000 个用户同时用就 x10000 ，除非不差钱可以无脑堆机器，不然不是重要的东西真的没必要放后端。
|
 |
24
IvanLi127 2022-04-13 11:20:19 +08:00 via Android
有可能有这种情况。前端做得好，后端再怎么拉，网站响应时间也能保持不错的样子。因为前端只要转圈圈告诉用户系统在处理，就是有响应。
|
Select Language