不得不说现在的前端应用越来越卡，越来越臃肿了

[nohup]

公司最近招了个前端，我是写 Python 后台的，他主要负责前端，主要就是做企业工具类的，放在外网给合作伙伴的业务人员用。
几个月下来开发过程中也没什么问题，那个前端最后开发倒是开发出来了，但是就是体积有点爆炸，6MB+的体积，经过 nginx 压缩也只能 5MB 的样子。我很纳闷不就几个页面吗？登录页、图表、表格，功能页也就二十来个，讲道理应该也没什么东西吧，他用的好像是 raect，吹的还很牛 B，什么单页面应用，函数式编程，组件化模块化。
然而每次打开页面都要等个半分钟，我们外网的小水管支撑不了这么多 4MB+的一次性请求，有时候用户用着不爽了干脆就投诉到我们老总了，搞得我每次都很尴尬。他们的投诉理由是服务器响应慢、当机了。。老总也天天问我怎么回事，能不能搞定，我说这是前端的问题他不信。。。
所以不得不感叹，现在的前端发展路线是不是走歪了？我记得以前我写个 login.html 效果贼漂亮，2s 就加载进来了，我该如何和前端沟通？是不是技术选型上这个 raect 不太合适呢？

[jasonyang9]

2 个地方都打成 raect 不是强迫症都不能忍了，自动 TAG 都歪成 raect 了

[yidinghe]

自从有了 electron，我再也不觉得 Java 桌面应用打开慢了。

[wly19960911]

单页面应用当然体积大，那我司的应用（ angular ）用户是不是要报警了？ 不过经过压缩的压缩包只有 6 M，首屏 gzip 加载 1.2 M，我不会 react，react 没有模块化的加载吗，这样基本不可能每次请求 4m 啊，而且水管小不考虑下 CDN 吗。

[TomatoYuyuko]

不上单页浑身难受系列
20 个页面直接写就行了，单页不做优化初次加载就是会慢一些

[sherryqueen]

不做分包的吗?

[my101du]

可能把本来放到 dev-dependency 的放到正式打包列表里面去了.... 毕竟以前我也经常这么干，然后骂 antd pro （匿）

[cstome]

React 不太清楚，像 Vue，不同模块是可以懒加载的，不一定要打包成一个 JS。

SPA 应用用 CDN 分发比较合理。


好吧，我用过的大部分 SPA 应用体验起来确实不咋地，所以我也不认可盲目追求 SPA 的行为。

[jy02534655]

这个没加缓存么，加了缓存的话会好点，也就是首次访问比较慢。感觉还是前端能力问题吧...

[abelmakihara]

你先让他做成按需加载的

[xrr2016]

登录页、图表、表格，功能页也就二十来个

[xrr2016]

@xrr2016 我觉得要是用了什么 D3，Echart 等库，加上一些图片，二十来个页面 dist 出来的也会很大

[jy02534655]

@xrr2016 用到这些可以调整加载策略的，启动的时候不加载，界面出来之后再偷偷加载就行了。

[banricho]

水平问题不要怪技术栈

[ShineSmile]

动静分离
异步加载

禁不住想起技术栈鄙视链 后端瞧不起 web 端 web 端瞧不起桌面端

[lygmqkl]

合理的设计思路和系统架构(前端)
模块＋异步加载
启用压缩
CDN 或者类似
另外。。。少加载点不需要的库。。。

[sucai]

按需加载+gzip 压缩了解一下，估计最后可以做到 1M 以内，我们现在的 500 多 K，也是引了两个图表库

[laike9m]

你做个最简单的页面，同一套后端，然后加载速度巨快，老版能不信是前端问题？

[tao1991123]

你不懂 + 他太水 = react 不适合你们的偏见

[learnshare]

跟技术选型有关，但并不怪 React

[yhxx]

我理解你是在吐槽前端水平，不过 6M 的文件为什么 nginx （应该是 gzip 或者 deflate 吧？）压缩之后变成 4M+？
正常情况应该是 1-2M 左右才对吧？

[yhxx]

“我们外网的小水管支撑不了这么多 4MB+的一次性请求”

这么大的文件居然没有 CDN ？运维是不是也要分点锅（手动滑稽

[duan602728596]

水不是问题，问题是俩人居然都不好好找找问题

[gamexg]

后端，临时学习 vue 写了个后台，带图表，整个也 2M，压缩只有 1M 多。

[wanghao2018]

用浏览器打开 network 看看哪一块体积大，分析分析啊 ， 哪有 6 兆的网站...

[xichengh]

只能说你们的前端菜。。。

[Biwood]

五线小厂，九流程序员的日常

[v2chou]

让他优化 还有 gizp 压缩后怎么还有这么大

[VDimos]

这事儿 react 不背锅，世界上那么多大型网站都运行在 react 上，从你们的程序员身上找问题

[KgM4gLtF0shViDH3]

比我们这个好多了，我司前端不会写网络请求…… js 一律不会，招人又不让我给面试

[Heavytiger]

我移动端，也做过 react。页面打开很快，就是请求 API 要慢点。感觉应该是后端 API 的问题。因为页面要等 api 返回数据，你半天不返回，你怪前端，这就不应该了。我就遇到过这个问题。上家公司，就找我，我把 api 请求时间发过去，10 几秒，立马就不找我了。

[no1xsyzy]

SPA 的话 6M 一般大小，主要还是
1. 按需加载（由 Webpack 提供，楼上几位说 Vue 只是因为 Vue 特地说了这点（难道说 Vue 写出来经常比 React 大所以……））；
2. 分发机制（ CDN，现在家用 20Mbps 打底吧…… 6/(20/8)= 2.4 两秒内没有任何问题）。
其中技术含量（难度） 1>2，体验优化 2>1。不过 1 能给 2 省钱。
但还有……没有设计渐进体验吗？—— NoScript 用户感

@yhxx 因为打包出来的 dist 6M 是已经混淆过的，函数命名都是单字母，信息量并不高，主要压缩掉的都是 `function(){` 和 `","`。说不定是因为假的函数式编程，所以 `function(){` 少了，能压缩的就不多了。

[sammo]

古典软件工程，追求的是 高性能、节省内存、节省硬盘空间、软件体积小。典型的就是 CHKenPlayer，一个不到 100KB 的软件 可以播放各种音频还有流媒体。

—— 内存不就是拿来用的？
—— 硬盘加钱
—— 上 SSD 阿
—— 摩尔定律阿 旧机器就是要淘汰的
—— 升级你的系统阿

这是你会听到的。当然 他们早就被看透了，也是不可能摧毁到对于古典软件工程真正有追求的人的，但是他们会稀释掉这个 “盘子” ，稀释的结果就是 改变人们对于 “古典软件工程” 的看法。当然 对于古典软件工程真正有追求的人 是不在意的，因为他们知道这是怎么回事。 —— 但是，在软件使用领域，一股 “消费、购买、系统升级” 的风气，逐渐弥漫开来 ——就像 当一群起哄的人坐在整个教室里的座位上，那么只能迎来更多乐于起哄的老师。当然，对于古典软件工程真正有追求的人 是不会被 劣币驱逐良币的，但 当那些人成为了 “老师” 的时候 ( 甚至所谓了借助开源的噱头 ) ，那么 在软件使用领域，可想而知，发展方向会如何

[sammo]

甚至所谓了借助开源的噱头 -> 甚至借助了所谓的‘开源’的噱头

[ayase252]

性能优化这方面要具体问题具体分析吧。像从减少体积方面就有代码分离和模块懒加载可以搞事情。

[feverzsj]

还有比阿里系更卡的前端吗？

[RqPS6rhmP3Nyn3Tm]

程序员水平肯定是越来越下降的啊，毕竟程序员的时间比电脑贵。上古时代的程序员我是真的敬佩，那帮做 8bit 游戏的，都是魔鬼吧

[ccbikai]

是你同事技术不行

[moocean]

我打包之后 20 兆，按需加载也很快啊，我们后台不会 gzip，哎

[wly19960911]

@BXIA #36 8bit 游戏的的确牛逼，还一个是 8bit 音乐的，因为他们不仅要会音乐，而且还要会汇编......

[yhxx]

@no1xsyzy 我说的是 nginx 层面的压缩
打包后 6M 大的 js 文件，到用户这里看到的正常情况下应该是在 2M 以内的


话说被投诉这么多，没什么改进措施？

[largecat]

前端要抢后端的活，搞那么多干嘛呢，

后端给他一堆 api 就行了，前端把 html 码漂亮点比什么都强，速度快不快就是后端的能力了

[no1xsyzy]

@yhxx gzip 不是字典+熵的压缩吗？我说的 function(){ 是字典啊
就像 jpg 再压缩效果不太好，如果本身熵基本满了实际上也压不了多少的。

[no1xsyzy]

@largecat SPA 不了解一下吗？说的是界面加载不快啊，API 的环节甚至还没出现，就已经慢了，那不是前端的事？
一个说法称一个界面加载 8 秒以上 90% 的人会失去耐心关闭界面（来源：七牛的广告）。
码得漂亮用户开不出没用的呀。

[yhxx]

@no1xsyzy uglify 只是语法层面的吧，处理后的体积应该和 gzip 的 LZ77 之类的算法比起来还是差很多的

[wly19960911]

@no1xsyzy #43 8 秒？首屏加载不应该超过 1M 吧。至少每个 SPA 一个首页，一个登录，基本过了这两关开始就压力减少很多了，首页和登录压不下来那真的有问题了。

[wee911]

可以延迟加载的啊，分开打包

[aaronly]

看了下我司的 React，JS + CSS 240K。
吓死我了，我还以为现在单页都是用 M 做单位的。

[yy77]

现在 google chrome 不是都带 network 分析的么？拉个图就知道到底是前端还是后端的问题了。就算是不懂的老板也很容易解释的。

[royzxq]

这不明显人的问题吗。。create-react-app 构建的项目自带 build 之后 analysis 可以看东西的大小。 什么？ 自己配的 webpack， 自己配的 webpack 会搞出这么奇葩的东西？

还有就是 webpack4 已经可以通过简单的配置分 chunk 了， 以及上面说的 vue 懒加载其实是 webpack 的功能。

总结一句话， 人菜不要怨栈。
就算你是 react, 照样怼出来具名路由和路由钩子（ react-router v4 ）。

最后一句，CRA 官方的脚本真的 like a shit.

[royzxq]

这个问题就算让他不写前端，直接套模板用 jq 之流也是一样的。

[AllOfMe]

@aaronly 是单页应用吗？如果引入了全家桶感还 240k 已经非常极限了，表示敬佩

[eslizn]

后端狗的开发机一直觉得性能不错（ i7/16G/SSD ）直到我用了某前端框架的 webpack

[lwbjing]

开发 5 分钟，配置 2 小时...

[xiangyuecn]

以前美工也是做个轮播图几个 mb 的导出来也不调一下品质，臭骂几顿就 300k 以下了。

今天刚改版好一个录音工具，github 测试页面，把 mp3、ogg、wav、webp 编码器全部加载出来，还带个 jquery。你猜花了 github 多少流量？

588kb ！ gzip 压缩了近 3 倍大小，哈 https://xiangyuecn.github.io/Recorder/

[o0]

把前端文件单独放云存储可解吧，再套个 cdn，你们都省事儿。

[RaymondYip]

明显是水平问题，就不要说框架了

[no1xsyzy]

@wly19960911 所以说需要代码分块啊，不分块在登录之前先要把所有模块给你加载好，这谁顶得住呀.jpg
@yhxx 其实还是碰运气吧，混淆本身是个破坏原本信息的行为，但熵减得可能并不如长度减少得多（甚至还有增加熵的可能）。有可能还是个命中 gzip 盲点的数据？实际上接触 .min.js 前谁也说不清到底能压多少。虽然一般可以对代码给个高期望，但也是可以落空的。

[yhxx]

@no1xsyzy 确实是运气。。。不过一般的 js 代码 gzip 掉个 60%还是可以期待的

其实楼主这种情况就是前端懒得搞。。。2 秒搞到 0.5 秒可能很难，从半分钟搞进 5 秒能做的太多了。。。

[encro]

连浏览器开发者工具都不会用么。随便看下就知道是哪里慢了。

[liuxey]

既然你是负责后端的，就不要和他扯前端技术，看你的描述，应该也没有性能测试之类的环节，
那么很简单分开部署，服务器加监控，每天出报告，一目了然！

[q397064399]

@BXIA #35
@sammo #31

工程追求的从来都不是技术的极致，如果有人认为工程是追求技术的极致，不是蠢就是傻，
任何项目都是妥协的结果，除非你钱里的钱能拿来当纸烧，那就追求技术的极致吧。

工程的目标从来都是 在投入有限资源的情况下，达成最不坏的目标。

现在上海的家用带宽都是 100M 起步 很多都是 1000M 了 ，上次办了个 20M 宽带 还被装宽带师傅 鄙视了一番。
就你那个小水管 好意思嘲笑前端 6MB 单页 打包起步？

[maplelin]

SPA 确实性能问题比较严重，不过做好优化使用体验也还好吧，路由异步加载，按需加载，压缩都做好的话应该不会首屏超过 2s 的，除非网络环境特别差

[bukip]

@ShineSmile #14 web 端瞧不起桌面端? 哪里来的自信？

[stariveer]

cdn 多缓存静态文件,dll 打包 lab 文件,粒度拆分好,前端不就是干这个的吗;)

[phpxiaowangzi]

@jasonyang9 歪成 raect 笑死了