首页   注册   登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
nohup
V2EX  ›  前端开发

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

  •  
  •   nohup · 2018-12-10 16:57:37 +08:00 · 5142 次点击
    这是一个创建于 408 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

    64 回复  |  直到 2018-12-12 17:33:37 +08:00
    jasonyang9
        1
    jasonyang9   2018-12-10 17:03:51 +08:00
    2 个地方都打成 raect 不是强迫症都不能忍了,自动 TAG 都歪成 raect 了
    yidinghe
        2
    yidinghe   2018-12-10 17:05:29 +08:00   ♥ 12
    自从有了 electron,我再也不觉得 Java 桌面应用打开慢了。
    wly19960911
        3
    wly19960911   2018-12-10 17:09:40 +08:00   ♥ 1
    单页面应用当然体积大,那我司的应用( angular )用户是不是要报警了? 不过经过压缩的压缩包只有 6 M,首屏 gzip 加载 1.2 M,我不会 react,react 没有模块化的加载吗,这样基本不可能每次请求 4m 啊,而且水管小不考虑下 CDN 吗。
    TomatoYuyuko
        4
    TomatoYuyuko   2018-12-10 17:11:08 +08:00
    不上单页浑身难受系列
    20 个页面直接写就行了,单页不做优化初次加载就是会慢一些
    sherryqueen
        5
    sherryqueen   2018-12-10 17:12:14 +08:00
    不做分包的吗?
    my101du
        6
    my101du   2018-12-10 17:13:38 +08:00
    可能把本来放到 dev-dependency 的放到正式打包列表里面去了.... 毕竟以前我也经常这么干,然后骂 antd pro (匿)
    cstome
        7
    cstome   2018-12-10 17:15:08 +08:00
    React 不太清楚,像 Vue,不同模块是可以懒加载的,不一定要打包成一个 JS。

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


    好吧,我用过的大部分 SPA 应用体验起来确实不咋地,所以我也不认可盲目追求 SPA 的行为。
    jy02534655
        8
    jy02534655   2018-12-10 17:15:51 +08:00
    这个没加缓存么,加了缓存的话会好点,也就是首次访问比较慢。感觉还是前端能力问题吧...
    abelmakihara
        9
    abelmakihara   2018-12-10 17:16:29 +08:00
    你先让他做成按需加载的
    xrr2016
        10
    xrr2016   2018-12-10 17:16:49 +08:00
    登录页、图表、表格,功能页也就二十来个
    xrr2016
        11
    xrr2016   2018-12-10 17:19:13 +08:00
    @xrr2016 我觉得要是用了什么 D3,Echart 等库,加上一些图片,二十来个页面 dist 出来的也会很大
    jy02534655
        12
    jy02534655   2018-12-10 17:27:35 +08:00
    @xrr2016 用到这些可以调整加载策略的,启动的时候不加载,界面出来之后再偷偷加载就行了。
    banricho
        13
    banricho   2018-12-10 17:30:45 +08:00   ♥ 1
    水平问题不要怪技术栈
    ShineSmile
        14
    ShineSmile   2018-12-10 17:34:38 +08:00
    动静分离
    异步加载

    禁不住想起技术栈鄙视链 后端瞧不起 web 端 web 端瞧不起桌面端
    lygmqkl
        15
    lygmqkl   2018-12-10 17:36:46 +08:00
    合理的设计思路和系统架构(前端)
    模块+异步加载
    启用压缩
    CDN 或者类似
    另外。。。少加载点不需要的库。。。
    sucai
        16
    sucai   2018-12-10 17:37:36 +08:00
    按需加载+gzip 压缩了解一下,估计最后可以做到 1M 以内,我们现在的 500 多 K,也是引了两个图表库
    laike9m
        17
    laike9m   2018-12-10 17:37:45 +08:00 via Android   ♥ 1
    你做个最简单的页面,同一套后端,然后加载速度巨快,老版能不信是前端问题?
    tao1991123
        18
    tao1991123   2018-12-10 17:37:55 +08:00
    你不懂 + 他太水 = react 不适合你们的偏见
    learnshare
        19
    learnshare   2018-12-10 17:38:56 +08:00
    跟技术选型有关,但并不怪 React
    yhxx
        20
    yhxx   2018-12-10 17:48:37 +08:00
    我理解你是在吐槽前端水平,不过 6M 的文件为什么 nginx (应该是 gzip 或者 deflate 吧?)压缩之后变成 4M+?
    正常情况应该是 1-2M 左右才对吧?
    yhxx
        21
    yhxx   2018-12-10 17:49:38 +08:00
    “我们外网的小水管支撑不了这么多 4MB+的一次性请求”

    这么大的文件居然没有 CDN ?运维是不是也要分点锅(手动滑稽
    duan602728596
        22
    duan602728596   2018-12-10 18:05:13 +08:00
    水不是问题,问题是俩人居然都不好好找找问题
    gamexg
        23
    gamexg   2018-12-10 18:07:32 +08:00
    后端,临时学习 vue 写了个后台,带图表,整个也 2M,压缩只有 1M 多。
    wanghao2018
        24
    wanghao2018   2018-12-10 18:08:19 +08:00
    用浏览器打开 network 看看哪一块体积大,分析分析啊 , 哪有 6 兆的网站...
    xichengh
        25
    xichengh   2018-12-10 18:13:43 +08:00
    只能说你们的前端菜。。。
    Biwood
        26
    Biwood   2018-12-10 18:20:52 +08:00
    五线小厂,九流程序员的日常
    v2chou
        27
    v2chou   2018-12-10 18:26:00 +08:00
    让他优化 还有 gizp 压缩后怎么还有这么大
    VDimos
        28
    VDimos   2018-12-10 18:29:15 +08:00 via Android
    这事儿 react 不背锅,世界上那么多大型网站都运行在 react 上,从你们的程序员身上找问题
    bestkayle
        29
    bestkayle   2018-12-10 18:31:08 +08:00 via iPhone
    比我们这个好多了,我司前端不会写网络请求…… js 一律不会,招人又不让我给面试
    Heavytiger
        30
    Heavytiger   2018-12-10 18:31:19 +08:00
    我移动端,也做过 react。页面打开很快,就是请求 API 要慢点。感觉应该是后端 API 的问题。因为页面要等 api 返回数据,你半天不返回,你怪前端,这就不应该了。我就遇到过这个问题。上家公司,就找我,我把 api 请求时间发过去,10 几秒,立马就不找我了。
    no1xsyzy
        31
    no1xsyzy   2018-12-10 18:33:35 +08:00
    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
        32
    sammo   2018-12-10 18:35:59 +08:00   ♥ 3
    古典软件工程,追求的是 高性能、节省内存、节省硬盘空间、软件体积小。典型的就是 CHKenPlayer,一个不到 100KB 的软件 可以播放各种音频还有流媒体。

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

    这是你会听到的。当然 他们早就被看透了,也是不可能摧毁到对于古典软件工程真正有追求的人的,但是他们会稀释掉这个 “盘子” ,稀释的结果就是 改变人们对于 “古典软件工程” 的看法。当然 对于古典软件工程真正有追求的人 是不在意的,因为他们知道这是怎么回事。 —— 但是,在软件使用领域,一股 “消费、购买、系统升级” 的风气,逐渐弥漫开来 ——就像 当一群起哄的人坐在整个教室里的座位上,那么只能迎来更多乐于起哄的老师。当然,对于古典软件工程真正有追求的人 是不会被 劣币驱逐良币的,但 当那些人成为了 “老师” 的时候 ( 甚至所谓了借助开源的噱头 ) ,那么 在软件使用领域,可想而知,发展方向会如何
    sammo
        33
    sammo   2018-12-10 18:39:58 +08:00   ♥ 1
    甚至所谓了借助开源的噱头 -> 甚至借助了所谓的‘开源’的噱头
    ayase252
        34
    ayase252   2018-12-10 18:52:03 +08:00
    性能优化这方面要具体问题具体分析吧。像从减少体积方面就有代码分离和模块懒加载可以搞事情。
    feverzsj
        35
    feverzsj   2018-12-10 18:53:07 +08:00
    还有比阿里系更卡的前端吗?
    BXIA
        36
    BXIA   2018-12-10 18:58:58 +08:00 via iPad   ♥ 2
    程序员水平肯定是越来越下降的啊,毕竟程序员的时间比电脑贵。上古时代的程序员我是真的敬佩,那帮做 8bit 游戏的,都是魔鬼吧
    ccbikai
        37
    ccbikai   2018-12-10 19:03:32 +08:00 via iPhone
    是你同事技术不行
    moocean
        38
    moocean   2018-12-10 19:10:19 +08:00
    我打包之后 20 兆,按需加载也很快啊,我们后台不会 gzip,哎
    wly19960911
        39
    wly19960911   2018-12-10 19:20:09 +08:00
    @BXIA #36 8bit 游戏的的确牛逼,还一个是 8bit 音乐的,因为他们不仅要会音乐,而且还要会汇编......
    yhxx
        40
    yhxx   2018-12-10 19:22:24 +08:00
    @no1xsyzy 我说的是 nginx 层面的压缩
    打包后 6M 大的 js 文件,到用户这里看到的正常情况下应该是在 2M 以内的


    话说被投诉这么多,没什么改进措施?
    largecat
        41
    largecat   2018-12-10 19:25:48 +08:00 via Android
    前端要抢后端的活,搞那么多干嘛呢,

    后端给他一堆 api 就行了,前端把 html 码漂亮点比什么都强,速度快不快就是后端的能力了
    no1xsyzy
        42
    no1xsyzy   2018-12-10 19:26:55 +08:00
    @yhxx gzip 不是字典+熵的压缩吗?我说的 function(){ 是字典啊
    就像 jpg 再压缩效果不太好,如果本身熵基本满了实际上也压不了多少的。
    no1xsyzy
        43
    no1xsyzy   2018-12-10 19:32:32 +08:00
    @largecat SPA 不了解一下吗?说的是界面加载不快啊,API 的环节甚至还没出现,就已经慢了,那不是前端的事?
    一个说法称一个界面加载 8 秒以上 90% 的人会失去耐心关闭界面(来源:七牛的广告)。
    码得漂亮用户开不出没用的呀。
    yhxx
        44
    yhxx   2018-12-10 19:37:43 +08:00
    @no1xsyzy uglify 只是语法层面的吧,处理后的体积应该和 gzip 的 LZ77 之类的算法比起来还是差很多的
    wly19960911
        45
    wly19960911   2018-12-10 19:37:50 +08:00
    @no1xsyzy #43 8 秒?首屏加载不应该超过 1M 吧。至少每个 SPA 一个首页,一个登录,基本过了这两关开始就压力减少很多了,首页和登录压不下来那真的有问题了。
    wee911
        46
    wee911   2018-12-10 20:02:51 +08:00
    可以延迟加载的啊,分开打包
    aaronly
        47
    aaronly   2018-12-10 20:47:17 +08:00
    看了下我司的 React,JS + CSS 240K。
    吓死我了,我还以为现在单页都是用 M 做单位的。
    yy77
        48
    yy77   2018-12-10 20:52:03 +08:00
    现在 google chrome 不是都带 network 分析的么?拉个图就知道到底是前端还是后端的问题了。就算是不懂的老板也很容易解释的。
    royzxq
        49
    royzxq   2018-12-10 21:00:01 +08:00
    这不明显人的问题吗。。create-react-app 构建的项目自带 build 之后 analysis 可以看东西的大小。 什么? 自己配的 webpack, 自己配的 webpack 会搞出这么奇葩的东西?

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

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

    最后一句,CRA 官方的脚本真的 like a shit.
    royzxq
        50
    royzxq   2018-12-10 21:01:19 +08:00
    这个问题就算让他不写前端,直接套模板用 jq 之流也是一样的。
    AllOfMe
        51
    AllOfMe   2018-12-10 21:35:54 +08:00 via Android
    @aaronly 是单页应用吗?如果引入了全家桶感还 240k 已经非常极限了,表示敬佩
    eslizn
        52
    eslizn   2018-12-10 22:18:37 +08:00
    后端狗的开发机一直觉得性能不错( i7/16G/SSD )直到我用了某前端框架的 webpack
    lwbjing
        53
    lwbjing   2018-12-10 22:21:35 +08:00
    开发 5 分钟,配置 2 小时...
    xiangyuecn
        54
    xiangyuecn   2018-12-10 22:40:27 +08:00   ♥ 1
    以前美工也是做个轮播图几个 mb 的导出来也不调一下品质,臭骂几顿就 300k 以下了。

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

    588kb ! gzip 压缩了近 3 倍大小,哈 https://xiangyuecn.github.io/Recorder/
    o0
        55
    o0   2018-12-10 23:37:50 +08:00 via iPhone
    把前端文件单独放云存储可解吧,再套个 cdn,你们都省事儿。
    RaymondYip
        56
    RaymondYip   2018-12-11 00:22:43 +08:00
    明显是水平问题,就不要说框架了
    no1xsyzy
        57
    no1xsyzy   2018-12-11 11:17:10 +08:00
    @wly19960911 所以说需要代码分块啊,不分块在登录之前先要把所有模块给你加载好,这谁顶得住呀.jpg
    @yhxx 其实还是碰运气吧,混淆本身是个破坏原本信息的行为,但熵减得可能并不如长度减少得多(甚至还有增加熵的可能)。有可能还是个命中 gzip 盲点的数据?实际上接触 .min.js 前谁也说不清到底能压多少。虽然一般可以对代码给个高期望,但也是可以落空的。
    yhxx
        58
    yhxx   2018-12-11 11:50:19 +08:00
    @no1xsyzy 确实是运气。。。不过一般的 js 代码 gzip 掉个 60%还是可以期待的

    其实楼主这种情况就是前端懒得搞。。。2 秒搞到 0.5 秒可能很难,从半分钟搞进 5 秒能做的太多了。。。
    encro
        59
    encro   2018-12-11 12:44:07 +08:00
    连浏览器开发者工具都不会用么。随便看下就知道是哪里慢了。
    liuxey
        60
    liuxey   2018-12-11 12:46:07 +08:00
    既然你是负责后端的,就不要和他扯前端技术,看你的描述,应该也没有性能测试之类的环节,
    那么很简单分开部署,服务器加监控,每天出报告,一目了然!
    q397064399
        61
    q397064399   2018-12-11 15:47:22 +08:00
    @BXIA #35
    @sammo #31

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

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

    现在上海的家用带宽都是 100M 起步 很多都是 1000M 了 ,上次办了个 20M 宽带 还被装宽带师傅 鄙视了一番。
    就你那个小水管 好意思嘲笑前端 6MB 单页 打包起步?
    maplelin
        62
    maplelin   2018-12-11 16:03:39 +08:00
    SPA 确实性能问题比较严重,不过做好优化使用体验也还好吧,路由异步加载,按需加载,压缩都做好的话应该不会首屏超过 2s 的,除非网络环境特别差
    bukip
        63
    bukip   2018-12-11 21:41:39 +08:00
    @ShineSmile #14 web 端瞧不起桌面端? 哪里来的自信?
    stariveer
        64
    stariveer   2018-12-12 17:33:37 +08:00
    cdn 多缓存静态文件,dll 打包 lab 文件,粒度拆分好,前端不就是干这个的吗;)
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   806 人在线   最高记录 5168   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.3 · 36ms · UTC 19:47 · PVG 03:47 · LAX 11:47 · JFK 14:47
    ♥ Do have faith in what you're doing.