chero
[置顶] 校招社招必备核心前端面试问题与详细解答
摘要： 本文总结了前端老司机经常问题的一些问题并结合个人总结给出了比较详尽的答案。网易阿里腾讯校招社招必备知识点。 原理讲解参考：前端增长-重新定义大前端 在线课程：网易云课堂课程 思否课堂 官方博客：前端学堂 fed123.com 1.关于性能优化说说js文件摆放顺序、减少请求、雪碧图等等原理， 说下wi 阅读全文
posted @ 2019-07-17 13:15 前端小屁孩 阅读(1125) 评论(0) 推荐(0) 编辑
2019年6月8日
高性能极致用户体验前端开发实战

课程介绍

高性能极致用户体验前端开发实战课程适合所有前端开发学习或者从业者，结合目前前端开发的最佳实践，提供前端网页性能分析优化知识，结合实际项目经验分析可以采用的优化思路，并给出开发高性能极致体验网页的通用方法和技巧。 课程官方博客：前端学堂 

在开始学习本课程之前，先提2个基本要求：

了解业务

作为一名合格的前端开发，我们的开发工作不是盲目的，我们的优化目标需要明确，所以首先要了解你所做的业务。不仅要知道整个业务背景，还需要了解业务需求，业务目的，最后最好能拿到业务结果。

了解业务的目的是能让你更好的分配开发的权重，合理安排开发的重点。比如开发的是视频类网站，那么开发的重点自然在于播放器加载和流畅播放以及降级方案。如果是天气类业务，那么核心业务是要保障稳定快速的展示出天气相关数据，然后是加载展示其他内容。如果是博文类网站，那么重点在于首屏的信息加载和展示。

了解用户

了解用户也是至关重要，如果连自己所做业务的受众都不知道，那么何谈用户体验，何谈极致性能？ 这一部分至少你要知道现在做的业务主要是面向PC用户还是移动web用户，PC用户所用的浏览器都是什么版本，比例分布是怎样？移动端用户android和ios比例多少，各自平台版本分布情况如何？这是最基本的要求，因为我们开发的代码是在这些平台运行的。 如果不知道怎么办？没关系，从今天开始统计起来，做个埋点日志服务，前端写个脚本上报下useragent就可以了。

  • navigator.userAgent
  • "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36"

 

课程大纲

  • 评判标准
    • RAIL评估模型
    • 性能指标
    • 体验指标
    • 指标数据采集
  • 优化实战
    • 链路优化
    • 编程优化
  • 链路优化
    • 链路阶段分析
    • 阶段指标数据
    • 各阶段优化手段
    • 案例分析和常用工具
  • 编程优化
    • 首屏渲染
    • 懒加载功能组件
    • 滚动加载分页组件
    • web worker计算
    • Task切分
    • 代码分割与打包
    • 前端开发架构优化
  • 前端开发架构优化
    • ES6 module+template
    • web component
    • 轻react或vue
    • 微前端架构

课程官方博客：前端学堂 

视频教程：云课堂视频课程

评判标准

无规矩不成方圆，所以这里先说说评判标准。评判标准主要指的是用户打开网页、浏览网页的体验和感受。我们需要一种客观的评估模型来统一量化用户体验的各个环节，这样才能找到需要优化的方向，找到开发极致用户体验网页的捷径。

RAIL评估模型

RAIL 是一种以用户为中心的性能模型。每个网络应用均具有与其生命周期有关的四个不同方面，且这些方面以不同的方式影响着性能。以用户为中心；最终目标不仅是让您的网站在任何特定设备上都能运行很快，而是使用户满意。

  • Response，立即响应用户；在 100 毫秒以内确认用户输入，超过100ms建议加上动效或者loading，通过视觉冲击减少用户等待的焦虑。
  • Animation，设置动画或滚动时，在 10 毫秒以内生成帧。
  • Idle，最大程度增加主线程的空闲时间。主线程空闲才能随时都可以及时响应。
  • Load，持续吸引用户；在 1000 毫秒以内呈现交互内容。

让用户成为您的性能工作的中心。用户花在网站上的大多数时间不是等待加载，而是在使用时等待响应。了解用户如何评价性能延迟：

延迟与用户反应
0 – 16 毫秒 流畅；人们特别擅长跟踪运动，如果动画不流畅，他们就会对运动心生反感。 用户可以感知每秒渲染 60 帧的平滑动画转场。也就是每帧 16 毫秒（包括浏览器将新帧绘制到屏幕上所需的时间），留给应用大约 10 毫秒的时间来生成一帧。
0 – 100 毫秒 快，在此时间窗口内响应用户操作，他们会觉得可以立即获得结果。时间再长，操作与反应之间的连接就会中断。
100 – 300 毫秒 可感觉慢，需要loading，用户会遇到轻微可觉察的延迟。
300 – 1000 毫秒 慢，需要做loading和占位。在此窗口内，延迟感觉像是任务自然和持续发展的一部分。对于网络上的大多数用户，加载页面或更改视图代表着一个任务。
1000+ 毫秒 很慢，超过 1 秒，用户的注意力将离开他们正在执行的任务。
10,000+ 毫秒 放弃，用户感到失望，可能会放弃任务；之后他们或许不会再回来。

响应：在 100 毫秒以内响应

在用户注意到滞后之前您有 100 毫秒的时间可以响应用户输入。这适用于大多数输入，不管他们是在点击按钮、切换表单控件还是启动动画。但不适用于触摸拖动或滚动。 如果您未响应，操作与反应之间的连接就会中断。用户会注意到。 尽管很明显应立即响应用户的操作，但这并不总是正确的做法。使用此 100 毫秒窗口执行其他开销大的工作，但需要谨慎，以免妨碍用户。如果可能，请在后台执行工作。 对于需要超过 500 毫秒才能完成的操作，请始终提供反馈机制，比如loading，进度条等。

动画：在 10 毫秒内生成一帧

动画不只是奇特的 UI 效果。例如，滚动和触摸拖动就是动画类型。 如果动画帧率发生变化，您的用户确实会注意到。您的目标就是每秒生成 60 帧，每一帧必须完成以下所有步骤：

从纯粹的数学角度而言，每帧的预算约为 16 毫秒（1000 毫秒 / 60 帧 = 16.66 毫秒/帧）。 但因为浏览器需要花费时间将新帧绘制到屏幕上，只有 10 毫秒来执行代码。 在像动画一样的高压点中，关键是不论能不能做，什么都不要做，做最少的工作。 如果可能，请利用 100 毫秒响应预先计算开销大的工作，这样您就可以尽可能增加实现 60fps 的可能性。 如需了解详细信息，请参阅渲染性能。

空闲：最大程度增加空闲时间

利用空闲时间完成推迟的工作。例如，尽可能减少预加载数据，以便您的应用快速加载，并利用空闲时间加载剩余数据。 推迟的工作应分成每个耗时约 50 毫秒的多个块。如果用户开始交互，优先级最高的事项是响应用户。

要实现小于 100 毫秒的响应，应用必须在每 50 毫秒内将控制权返回给主线程，这样应用就可以执行其像素管道、对用户输入作出反应，等等。以 50 毫秒块工作既可以完成任务，又能确保及时的响应。

加载：在 1000 毫秒以内呈现内容

在 1 秒钟内加载您的网站。否则，用户的注意力会分散，他们处理任务的感觉会中断。侧重于优化关键渲染路径以取消阻止渲染。 实际操作中，我们无需在 1 秒内加载所有内容以产生完整加载的感觉，而是启用渐进式渲染和在后台执行一些工作，默认只加载和渲染首屏内容，将非首屏、非必需的加载推迟到空闲时间段处理。

关键 RAIL 指标汇总

要根据 RAIL 指标评估您的网站，请使用 Chrome DevTools Timeline 工具记录用户操作。然后根据这些关键 RAIL 指标检查 Timeline 中的记录时间。

RAIL 步骤关键指标用户操作
响应 输入延迟时间（从点按到绘制）小于 100 毫秒。 用户点按按钮（例如打开导航）。
动画 每个帧的工作（从 JS 到绘制）完成时间小于 16 毫秒。 用户滚动页面，拖动手指（例如，打开菜单）或看到动画。 拖动时，应用的响应与手指位置有关（例如，拉动刷新、滑动轮播）。 此指标仅适用于拖动的持续阶段，不适用于开始阶段。
空闲 主线程 JS 工作分成不大于 50 毫秒的块。 用户没有与页面交互，但主线程应足够用于处理下一个用户输入。
加载 页面可以在 1000 毫秒内就绪。 用户加载页面并看到关键路径内容。

这是Google工程师提出来的RAIL优化模型，在实际前端业务监控中，我们可以拆分成更多的数据指标进行统计分析。

性能和体验数据指标

数据驱动业务开发，我们的目标是高性能和极致用户体验，那么我们首先需要制定符合我们目标的性能数据指标和体验数据指标。 在制定数据指标之前，我们分析下页面加载过程，我们分为这四个部分：

用户体验描述
它在发生吗？happening 网页浏览顺利开始了吗？服务端有响应吗？
它是否有用？useful 用户是否能看到足够的内容？
它是否可用？usable 用户是否可以和页面交互，还是页面仍在忙于加载？
它是否令人愉快的？idle 交互是否流程和自然，没有卡段或闪烁？

 

性能指标：加载呈现又快又稳。加载到展现的性能指标和稳定性指标。

体验指标：操作反应灵敏。点击，滑动等交互响应及时，操作流畅，动画运行流畅。

 

加载性能指标：
  • 秒开率：页面首屏加载时间小于1s的比例，也就是页面加载到onload事件触发时所消耗的时间。
  • FP（first paint） 和 FCP（first content paint） 分别是指页面首次绘制和首次内容绘制。FP（首次绘制）包括了任何用户自定义的背景绘制，它是首先将像素绘制到屏幕的时刻。FCP（首次内容绘制）是浏览器将第一个 DOM 渲染到屏幕的时间。该指标报告了浏览器首次呈现任何文本、图像、画布或者 SVG 的时间。这两个指标其实指示了我们通常所说的白屏时间。
  • FMP(first meaningful paint)首次有意义绘制, 是页面可用性的度量标准。因为很难有一个通用标准来指示所有的页面当前时刻的渲染达是否到了有用的程度，所以当前并没有制定标准。对于开发者，我们可以根据自己的页面来确定那一部分是最重要的，然后度量这部分渲染出的时间作为FMP。
  • TTFB(time to first byte, 首字节时间)，是指从浏览器发起第一个请求到数据返回第一个字节所消耗的时间，这个时间包含了网络时间，后端处理时间等等，可以作为一个链路数据综合参考指标。

稳定性指标

  • 资源错误：静态资源加载错误，常见的就是404，资源地址不正确或者远程服务有问题。
  • JS报错：页面运行时抛出来的异常信息。比如变量未定义，函数报错等等。
  • Crash：页面白屏不展示内容，很可能是页面某个模块报错导致整个页面不展示。
  • 内存堆栈：监控页面内存和堆栈使用情况，常见如页面内存泄露等原因会直接导致APP闪退。
  • 接口报错：接口挂了，请求超时。或者接口返回了错误信息。或者接口返回数据错误，比如空数据，不符合预期。
操作体验指标：
  • 交互延迟：用户点击后页面没有响应或者响应时间超过100ms，用户感觉这次点击操作是延迟的（可称为无效点击）。通过EventTiming API我们可以统计用户交互操作后的浏览器响应时间。
  • 卡顿：统计浏览器中执行时间超过 50 ms 的任务，都是 long task（Long tasks API ），可能会造成页面卡顿。
  • 滚动流畅性：滚动过程是否流畅，监测用户开始操作到页面开始滚动的时间差，按照前面的标准，小于100ms才会体验流畅。
  • 动画流畅性：监测动画开始到动画结束，计算帧率FPS。按照前面的标准，每帧计算时间小于10ms才会体验流畅。
  • TTI（time to interactive, 可交互时间)：指页面已渲染出内容，同时可以响应用户的输入的时间。
  • FID（First Input Delay），首次输入延迟，从用户看到页面到第一次输入的延迟，一般都是因为主线程阻塞，会导致响应慢。这个指标反映用户对当前页面的第一感觉，如果用户很久没有交互，说明首屏内容比较吸引人，或者用户很快就切走了，说明对用户没有吸引力。

 

性能指标数据采集

介绍上面我们总结的性能和体验指标如何准确有效的采集。

 

优化实战

我们已经全面分析总结了评估页面性能和用户体验的各个指标参数。那么怎么来优化呢？open signal官方提供了2018年2月份统计的全世界4G网络覆盖率和通信速率的统计分布图如下，在目前移动互联网的浪潮下，我们要利用好用户终端设备的每个字节的流量。

当然页面性能和体验优化并不是一蹴而就的，需要不断的研究、跟踪，发现问题，解决问题。但是我们可以在一开始编写业务代码的时候就做的更好，做到极致。所以，关于优化实战我们主要分为两部分：加载渲染链路优化 和 编程代码优化。

加载渲染链路优化

从访问url到页面呈现，整个加载和渲染链路可以做优化的思路。

加载链路：浏览器导航开始->检查缓存->DNS->HTTP->解析

渲染链路：浏览器内核或者webview（对于ios区分wkwebview和早期版本的uiwebview）渲染流程

具体详情参看下面这篇文章：

 

编程代码优化

我们说的“快”，并不仅仅指浏览器器加载页面快，就是常说的秒开率，一般指DomContentLoad时间。但是“快”其实包含更多的含义，除了前面说的浏览器加载快，还包含浏览器解析快（Javascript脚本发布时通常都会做代码压缩混淆，不仅是减少体积，也为了安全性），JS脚本编译快（我们知道javascript在浏览器的javascript虚拟机【managed runtime environment for JavaScript，JavaScript托管运行时环境】中运行的，所以也需要编辑JS脚本成字节码，才能运行），最后一个就是javascript执行快。

链路优化中，我们已经解决了JavaScript下载加速的问题，那么剩下的优化工作主要集中在优化浏览器解析、编译并执行JS脚本。影响浏览器解析和执行JS脚本的因素主要是JS脚本的体积大小和代码的复杂程度。所以编程代码优化实践主要是减少代码的体积和按需降低代码复杂度，实现浏览器解析快，JS脚本编译快。

  • 代码体积大，加载就会耗时，而且占用cdn存储资源和http请求资源，浏览器解析时暂用内存多，分析代码耗时。
  • 代码复杂度高，代码解析就比较耗时。如果依赖一些复杂的类库，还要考虑库的解析和执行时间。浏览器解析代码会占用更多内存，使用堆栈更深，执行耗时。

优化策略：

  • 首屏渲染与PRPL
  • 懒加载组件
  • 滚动加载分页组件
  • web worker
  • task拆分
  • 代码分割与打包
  • 项目架构优化

具体详情参看下面这篇文章：前端极致性能体验编码框架优化

 

参考

posted @ 2019-06-08 12:00 前端小屁孩 阅读(1570) 评论(0) 推荐(1) 编辑
2017年9月4日
http请求代理proxy-ajax
摘要： 今天把项目中的反向代理脚本程序抽成了一个插件，通过配置文件配置代理的http请求，这样使用起来比较方便，每位开发成员都可以用自己配置的代理调试代码。也可以用来直接做http代理，你甚至都不用Charles或者fiddler，直接开启proxy-ajax，然后手机上设置代理就可以了。 git prox 阅读全文
posted @ 2017-09-04 16:53 前端小屁孩 阅读(8010) 评论(0) 推荐(0) 编辑
2013年12月6日
如何应对pm2.5
摘要： 细颗粒物又称细粒、细颗粒。PM2.5：指环境空气中空气动力学当量直径小于等于 2.5微米的颗粒物，也称细颗粒物。能较长时间悬浮于空气中，其在空气中含量（浓度）越高，就代表空气污染越严重。可吸入颗粒物又称为PM10，指空气动力学当量直径在10微米以下的颗粒物。[1]在职业危害相关技术标准中，将能够较长时间悬浮于空气中的固体颗粒统称为“粉尘”。PM2.5是指大气中直径小于或等于2.5微米的颗粒物，也称为可入肺颗粒物。它的直径还不到人的头发丝粗细的1/20。虽然PM2.5只是地球大气成分中含量很少的组分，但它对空气质量和能见度等有重要的影响。与较粗的大气颗粒物相比，PM2.5粒径小，比表面积大，.. 阅读全文
posted @ 2013-12-06 18:41 前端小屁孩 阅读(403) 评论(0) 推荐(0) 编辑
2013年11月23日
补肾的食物有哪些，吃什么补肾，专家建议初冬宜补肾
摘要： 感冒是冬季常见病，特别是中老年人，一个月就感冒两三次，每次十天半月都不好，这到底是什么原因呢？ 现代医学证明：感冒病毒主要侵袭的是呼吸系统，即人体的肺。这跟中医讲的“肾”有着密切的关系，中医讲“肺主气，肾主纳气”，肾气衰弱，就会导致肺气及元气不足，机体免疫力变差，防御病毒能力减弱，感冒几率就会增加。 《黄帝内经》曰：“人到中年，肾气自半”。意即人到中年肾气逐年减弱，肾中元气不足，人体免疫力也处于低迷状态。现代医学研究也证实了这一点：人在40岁以后，体内调控衰老和免疫的T细胞，其凋亡率会明显高于年轻人，而通过服用补肾益寿胶囊后，首先观察到免疫T细胞凋亡率显著下降，其次是机体免疫力增强，感冒... 阅读全文
posted @ 2013-11-23 16:04 前端小屁孩 阅读(221) 评论(0) 推荐(0) 编辑
2012年12月18日
prim算法---java实现
摘要： 最小生成树是数据结构中图的一种重要应用，它的要求是从一个带权无向完全图中选择n－1条边并使这个图仍然连通（也即得到了一棵生成树）,同时还要考虑使树的权最小。 为了得到最小生成树，人们设计了很多算法，最著名的有prim算法和kruskal算法（见上一篇博客）。算法描述：假设V是图中顶点的集合，E是图中边的集合，TE为最小生成树中的边的集合，则prim算法通过以下步骤可以得到最小生成树： 1：初始化：U={u 0},TE={f}。此步骤设立一个只有结点u 0的结点集U和一个空的边集TE作为最小生成树的初始形态，在随后的算法执行中，这个形态会不断的发生变化，直到得到最小生成树为止。 2：在所... 阅读全文
posted @ 2012-12-18 16:39 前端小屁孩 阅读(2575) 评论(0) 推荐(1) 编辑
kruskal算法---JAVA实现
摘要： 克鲁斯卡尔算法(Kruskal's algorithm)是两个经典的最小生成树算法的较为简单理解的一个。这里面充分体现了贪心算法的精髓。算法如下：假设T中的边和顶点均涂成红色，其余边为白色。开始时G中的边均为白色。 1）将所有顶点涂成红色； 2）在白色边中，挑选一条权最小的边，使其与红色边不形成圈，将该白色边涂红； 3）重复2）直到有n-1条红色边，这n-1条红色边便构成最小生成树T的边集合。 注意到在算法执行过程中，红色顶点和红色边会形成一个或多个连通分支，它们都是G的子树。一条边与红色边形成圈当且仅当这条边的两个端点属于同一个子树。因此判定一条边是否与红色边形成圈，只需判断这条边的 阅读全文
posted @ 2012-12-18 14:22 前端小屁孩 阅读(3431) 评论(0) 推荐(2) 编辑
2012年12月6日
oracle中decode函数 VS mysql中的if函数和case函数
摘要： oracle中有decode函数，如下： select sum（decode（sex，'男'，0,1）） 男生数 from school；统计男生数目，含义为：decode（）中sex字段为男时，用1代替，然后计算总和而mysql中没有该函数，替代的有case与if函数。case函数同样统计男女生人数，语句如下：SELECT school,COUNT(school) 人数, SUM(CASE WHEN sex='男'THEN 1 ELSE 0 END) 男生数, SUM(CASE WHEN sex='女'THEN 1 ELSE 0 END) 女. 阅读全文
posted @ 2012-12-06 14:31 前端小屁孩 阅读(20127) 评论(1) 推荐(0) 编辑
2012年12月5日
v4L2编程
摘要： v4L2编程 v4L2是针对uvc免驱usb设备的编程框架，主要用于采集usb摄像头等，编程模式如下：一．设置采集方式 打开视频设备后，可以设置该视频设备的属性，例如裁剪、缩放等。这一步是可选的。在Linux编程中，一般使用ioctl函数来对设备的I/O通道进行管理：extern int ioctl (int __fd, unsigned long int __request, …) __THROW;__fd：设备的ID，例如刚才用open函数打开视频通道后返回的cameraFd；__request：具体的命令标志符。在进行V4L2开发中，一般会用到以下的命令标志符：VIDIOC_REQBU. 阅读全文
posted @ 2012-12-05 22:58 前端小屁孩 阅读(5075) 评论(0) 推荐(1) 编辑
元启发式算法（Metaheuristic algorithm）
摘要： 元启发式算法（Metaheuristic algorithm） 计算机科学的两大基础目标，就是发现可证明其执行效率良好且可得最佳解或次佳解的算法。而启发式算法则试图一次提供一或全部目标。 例如它常能发现很不错的解，但也没办法证明它不会得到较坏的解；它通常可在合理时间解出答案，但也没办法知道它是否每次都可以这样的速度求解。 有时候人们会发现在某些特殊情况下，启发式算法会得到很坏的答案或效率极差，然而造成那些特殊情况的数据结构，也许永远不会在现实世界出现。因此现实世界中启发式算法常用来解决问题。启发式算法处理许多实际问题时通常可以在合理时间内得到不错的答案。有一类的通用启发式策略称为元启发式算法. 阅读全文
posted @ 2012-12-05 22:00 前端小屁孩 阅读(6586) 评论(0) 推荐(0) 编辑
下一页

< 2025年4月 >
日 一 二 三 四 五 六
30 31 1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 1 2 3
4 5 6 7 8 9 10
Copyright © 2025 前端小屁孩
Powered by .NET 9.0 on Kubernetes Powered By博客园
点击右上角即可分享
微信分享提示