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

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

  •  
  •   nohup · 101 天前 · 4123 次点击
    这是一个创建于 101 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

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

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


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

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

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

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

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


    话说被投诉这么多,没什么改进措施?
        41
    largecat   101 天前 via Android
    前端要抢后端的活,搞那么多干嘛呢,

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

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

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

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

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

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

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

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

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

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