等待js文件下载完成 -> 5. 等待js加载并初始化完成 -> 6. js代码终于可以运行,由js代码向后端请求数据( ajax/fetch ) -> 7. 服务器初始渲染(服务端性能好,较快) -> 4. 服务端返回已经有正确内容的页面 -> 5. 客户端请求js/css文件 -> 6. 等待js文件下载完成 -> 7. 即:服务端渲染,实际上也是需要客户端进行 再次地、但开销很小的二次渲染。 前端渲染的优势 局部刷新。无需每次都进行完整页面请求 懒加载。 增加了前端的工作量,需要多维护node层。 解决方案: 一、前端和后端先行讨论对接,确定哪些是前端渲染哪些是后端渲染,确定字段,接口格式。 前端渲染的部分,又分为2种, 1、前端模板,vue、react去绑数据,实现方式为virtual Dom。
最近自己尝试翻译了几篇外文的技术文章,发现了一些经典文章内容已经过时,如 「How JavaScript works: inside the V8 engine + 5 tips on how to 通过优化关键渲染路径,我们可以显著缩短首次渲染页面的时间。 此外,了解关键渲染路径还可以为构建高性能交互式应用打下基础。 如果 DOM 或 CSSOM 被修改,只能再执行一遍以上所有步骤,以确定哪些像素需要在屏幕上进行重新渲染。 优化关键渲染路径就是指最大限度缩短执行上述第 1 步至第 5 步耗费的总时间。 令牌化: 浏览器将字符串转换成 W3C HTML5 标准规定的各种令牌,例如,“<html>”、“<body>”,以及其他尖括号内的字符串。每个令牌都具有特殊含义和一组规则。 在上例中,将一堆 HTML 字节转换成 DOM 树大约需要 5 毫秒。对于较大的页面,这一过程需要的时间可能会显著增加。创建流畅动画时,如果浏览器需要处理大量 HTML,这很容易成为瓶颈。
对于内容复杂和变更频繁的前端应用,页面渲染也常常是性能优化的核心场景。前面我有给大家整体地讲过《前端性能优化--方案归纳篇》,其实里面已经囊括了大多数场景下的一些性能优化的方向。 关于加载流程相关的优化,也有在《前端性能优化--加载流程篇》一文中进行详细的介绍。本文主要围绕页面渲染相关的内容,来进行性能优化分析。首屏渲染说到页面渲染,首屏的渲染显然是最首要的。 实际上,对于首屏内容的优化,前端开发在项目中更常用的点是骨架屏、数据分片/分屏加载、SSR DOM 直出渲染这几种,因为这几个优化点相对来说方向明确、效果明确、实现相对简单。 虽然现在大多数前端项目都离不开前端框架,也正因为这些框架本身已经做了很多的优化,所以我们常常会忘记和忽略掉这些注意事项。 结束语本文主要围绕页面渲染和更新的过程,介绍了一些性能优化的方向。其实如果你有注意到,就会发现本文的内容大多数还是基础和简单的前端知识点。
最好是通过 javascript动态给 iframe 添加 src 属性值, 这样可 绕开以上两个问题 禁止使用 gif 图片实现 loading 效果 ( 降低 CPU 消耗,提升渲染性能 避免文件跨域 修改及时生效 页面头部的 <style></style> <script></script> 会阻塞页面;( 因为 Renderer 进程中 JS 线程和渲染线程是互斥的 ) 页面中空的 href 和 src 会阻塞页面其他资源的加载 (阻塞下载进程) 网页 gzip , CDN 托管, data 缓存 , 图片服务器 前端模板 JS+数据,减少由于 HTML 标签导致的带宽浪费 , 前端用变量保存AJAX请求结果,每次操作本地变量,不用请求,减少请求次数 用 innerHTML 代替 DOM 操作,减少 DOM 操作次数,优化 javascript 性能 当需要设置的样式很多时设置
内容来源:2018 年 6 月 30 日,饿了么前端主管向勇在“饿了么技术沙龙・第27弹 【前端专场】”进行《h5渲染性能一瞥》演讲分享。 阅读字数:2488 | 7分钟阅读 摘要 前端性能按照类型来分主要分为加载性能和渲染性能。加载性能对于首屏的展示及其重要,而渲染性能对于页面加载完成后的交互体验极其重要。 但目前绝大部分同学在提到前端性能的优化时都会默认等同于对加载性能的优化,而忽略了渲染性能。本次议题就从几个比较常见的角度聊聊开发中会无意识碰到的渲染性能问题。 H5 VS Native 在将H5和native进行对比的时候,我们通常能想到的一点就是“快”,H5相对于native开发和上线都会快一些,一般的活动页面和非关键页面更多的倾向于H5来开发。 当然H5也有相应的缺点,它的加载和操作会慢一些,抽象来看就是性能问题。加载慢对应的是加载性能,操作慢对应的是渲染性能。
作者:winkchen 腾讯IEG前端开发工程师 |导语 web前端技术中,有个叫做jsx的模板渲染语法,它是一个JavaScript 的语法扩展,目前逐渐被行业标准化(用的人多了...)。 实际上jsx 是来源于一个前端框架 react。在react中除了我们了解的jsx,那么jsx在react的渲染过程是哪个环节生效,以及渲染过程经历了哪些步骤。本文会基于这些点进行概述。 一.介绍前的建议 1.本文的react.render树状图.xmind,此为作者查看/调试react的渲染源码时做的结构笔记。
React to Render
这十年,前端渲染方式一直在演进,我觉得大概可以分为以下三个阶段: 传统 SSR: 那时候前端还没有分离,在 JSP、ASP、Ruby on Rails、Django 这些 MVC 框架下,通过模板来渲染页面 前端可以专注于 UI 的设计和交互逻辑。后端只需要提供 API,不需要关心前端的具体实现。 同构前端:这几年前端框架的发展进入的深水区,随着云原生、容器技术、Serverless、边缘计算等底层技术设施的普及,也让‘前端’生存范围延展到服务端。 前端开始寻求 UX 和 DX 的平衡点 通过这篇文章,你就可以知道近些年前端渲染模式的演变。 废话不多说,直接开始吧。 CSR - 客户端渲染 这个我们再熟悉不过了, 即前端页面在浏览器中渲染,服务端仅仅是静态资源服务器(比如 nginx)。
在怪异模式下,排版会模拟 Navigator 4 与 Internet Explorer 5 的非标准行为。标准模式下,行为即由 HTML 与 CSS 的规范描述的行为。 图1-1:浏览器渲染引擎族谱 ? 2. 浏览器如何决定用哪个模式 ? 浏览器使用文件开头的 DOCTYPE 来决定用怪异模式处理或标准模式处理。 <!DOCTYPE html> <! DOCTYPE html>,是所有可用的 DOCTYPE 之中最简单的,而且是HTML5 所推荐的。 3.1. document.compatMode document.compatMode 可以表明当前文档的渲染模式是混杂模式还是"标准模式". 当一个元素使用百分比高度时,在 IE Standards Mode 下,高度取决于内容的变化,而在 IE5 Quirks Mode 下,百分比高度则被正确应用。
默认情况下,CSS 被视为阻塞渲染的资源,这意味着浏览器将不会渲染任何已处理的内容,直至 CSSOM 构建完毕。请务必精简您的 CSS,尽快提供它,并利用媒体类型和查询来解除对渲染的阻塞。 在 渲染树构建(可查看上篇文章) 中,我们看到关键渲染路径要求我们同时具有 DOM 和 CSSOM 才能构建渲染树。这会给性能造成严重影响:HTML 和 CSS 都是阻塞渲染的资源。 HTML 显然是必需的,因为如果没有 DOM,我们就没有可渲染的内容,但 CSS 的必要性可能就不太明显。如果我们在 CSS 不阻塞渲染的情况下尝试渲染一个普通网页会怎样? 浏览器将阻塞渲染,直至 DOM 和 CSSOM 全都准备就绪。 CSS 是阻塞渲染的资源。需要将它尽早、尽快地下载到客户端,以便缩短首次渲染的时间。 根据网页加载时设备的方向,portrait.css 可能阻塞渲染,也可能不阻塞渲染。 最后一个声明只在打印网页时应用,因此网页首次在浏览器中加载时,它不会阻塞渲染。
DOCTYPE html> 2 <html lang="en"> 3 <head> 4 <meta charset="UTF-8"> 5 <title>vue6</title> --vue会尽可能高速的渲染元素,通常是复用已有元素--> 20 <! --这样每次切换时,输入框都会被重新渲染--> 35 <template v-if="loginType==='username' "> 36 <label for="um1"> 这里再补充两点: 1.html中的<template>元素是一种保存客户端内容的机制,该内容在页面加载时不被渲染,但是运行时可以使用js实例化。 2.v-if与v-show的区别: v-show只是简单的切换css属性display,元素始终被渲染被保存在DOM中; v-show的切换开销相比v-if小,但是初始渲染开销比v-if大; 因此频繁切换
DOCTYPE html> 2 <html lang="en"> 3 <head> 4 <meta charset="UTF-8"> 5 <title>vue6</title> --vue会尽可能高速的渲染元素,通常是复用已有元素--> 20 <! --这样每次切换时,输入框都会被重新渲染--> 35 <template v-if="loginType==='username' "> 36 <label for="um1"> 这里再补充两点: 1.html中的<template>元素是一种保存客户端内容的机制,该内容在页面加载时不被渲染,但是运行时可以使用js实例化。 2.v-if与v-show的区别: v-show只是简单的切换css属性display,元素始终被渲染被保存在DOM中; v-show的切换开销相比v-if小,但是初始渲染开销比v-if大; 因此频繁切换
浏览器的渲染页面过程 HTML解析过程 一般情况下服务器会给浏览器返回 xx.html 文件 解析html 其实就是 Dom 树的构建过程 我们可以根据以下html 结构 来简单的分析出 html Render Tree的构建过程 Render Tree和DOM Tree并不是一一对应的关系,比如对于display为none的元素,压根不会出现在render tree中; 解析步骤 布局和绘制 渲染树 frame转为屏幕上实际的像素点; 包括将元素的可见部分进行绘制,比如文本、颜色、边框、阴影、替换元素(比如img) 渲染的流程可以参考下图 : 完成以上五步 成功在浏览器渲染出 对应的 xx.html 文件 回流和重绘 回流(reflow) reflow : 我们渲染出来的节点大小位置 也就是布局时第一次渲染出之后就确定的 之后对于节点大小和位置重新计算的行为 叫做回流(reflow) 回流在什么时候会出现 在渲染html的时候 js 没有继续构造DOM的能力 如果需要需要的部分 会先停止构建,下载js 执行脚本 把需要构建的东西构建完成后 继续执行构建 DOM 这么做有什么好处?
面试常见问题: 如何渲染十万条数据 最直接的方法就是直接渲染出来,但是这样的做法肯定是不可取的,因为直接渲染太耗性能了。 提高渲染性能的解决方案有如下: 虚拟列表(也叫按需渲染或可视区域渲染) 时间分片 虚拟列表是最主流的解决方案,不渲染所有的数据,只渲染可视区域中的数据。 01 直接渲染 通过for 直接渲染,太消耗性能
开篇 前端同构渲染的相关架构,给我最直观的感受,这是前端渲染最为复杂的一种方案,也是为了追求极致的用户体验不得不去做的一种尝试,虽然 Node.js 的引入赋能了传统前端领域、SEO 优化也不再是个问题 Node.js 的出现极大程度的给传统前端赋予了更大的能量,前端的分离也从前期的物理文件的区分转变为职责上的区分,前端开发者从页面仔的噩梦中解脱出来,最重要的是,JavaScript 能在服务器端执行了 再议首屏 让我们把视角移动的更细致一些,关注『从服务器端输出 HTML』这一部分,其隐藏的含义是我们需要把 App 渲染的所有 HTML 都输出给前端,其实不然,举个栗子: 比如在移动端有一个页面,它有大约 HTML 字符串做缓存策略,在缓存(一般选择 redis 等方案)之后,下次直接将同样的页面直接输出到前端,可大幅提高渲染性能。 原文作者:蚂蚁保险体验技术 原文链接: https://juejin.im/post/5c821dc45188257e1f2915b1
写在前面 React、Vue 等现代化前端框架的大旗之下,CSR(Client-Side Rendering)模式深入人心: CSR (Client-Side Rendering) – rendering 前端部分几乎全都是由客户端动态渲染(客户端执行 JS 代码,动态创建 DOM 结构)出来的,例如: <! : SSR(Server-Side Rendering):服务端渲染,在服务端将 Web 应用渲染成 HTML Rehydration:二次渲染,复用服务端渲染的 HTML DOM 结构和数据,在客户端 ,叫预渲染(Prerendering) Prerendering 主要区别在于,静态渲染得到的页面已经是可交互的,无需在客户端额外执行大量 JS 代码,而预渲染必须经客户端渲染才真正可交互: Static ) 对于二次渲染造成交互无法响应的问题,可能的优化方向是增量渲染(例如React Fiber),以及渐进式渲染/部分渲染 Trisomorphic Rendering 如果把Service Worker
在前端性能优化中,尤其是动画绘制中,我们需要关注浏览器的渲染频率FPS(每秒传输帧数(Frames Per Second)),在Chrome浏览器上我们可以通过Performance 查看渲染Fps: [image] 在前端性能检测需求中,我们可以计算浏览器的渲染帧数。 实现思路 window.requestAnimationFrame()是我们写动画经常使用的方法,根据浏览器的的渲染频率绘制页面,减少不必要的计算和动画绘制过程,requestAnimationFrame
前端渲染的发展 在讲ESR(Edge Side Rendering,边缘渲染)如何提速渲染之前,我们有必要先了解一下前端渲染的发展历史以及前端各项性能指标优化是如何被提上议程的,之后我们再反观ESR的出现就会发现也是水到渠成 其实整个前端渲染方式也是随着前端技术的演进而不断革新的,大致可以分为如下历程。 SSR(Server Side Rendering)时代(JSP、PHP) 最早期的前端渲染(2005年Ajax推出之前)都是和后端混写的,比如JSP、PHP等写法。 CSR(Client Side Rendering)时代 后面有了Ajax技术之后,再加上通过CDN缓存静态资源之后,前端SPA + CSR渲染有了飞跃式的发展,这种模式前端处理所有逻辑、内容填充和路由 但是由于请求是全异步的,其一是对SEO不利,其二是需要HTML + JS处理数据拼接才能在前端完成渲染,其首屏白屏时间会较长,特别在一些低端机型上体验更是堪忧 SSR时代(Node) 再后来随着Node
PS:我们是字节游戏中台前端团队,日常学习氛围浓厚,最近听说要 10-7-5 了,还有大量 HC,欢迎自荐。 一、啥是「啥是 XXR ?」? 前端研发中有许多常见场景,根据不同的构建、渲染过程有不同的优劣势和适用情况。 二、渲染模式——概念与对比 这里所说的 ✌ 渲染模式 ✌,包括: 页面 / 应用在开发完成之后的产物编译方式; 部署上线之后的服务形态; 资源存储与分发的方式; 用户访问时的启动与渲染过程; 这几方面不同的实现和规范 2.1 CSR for Client Side Rendering 顾名思义的“客户端渲染”,是当下用于渲染各类 UI 库构建的前端项目的最常见方案。 2.1.1 啥是 CSR? SSR 的概念,即与 CSR 相对地,在服务端完成大部分渲染工作,其实这就是一开始还没有如今的前端的时候,页面的呈现方式——服务器在响应站点访问请求的时候,就已经渲染好可供呈现的页面。
最近在研究页面渲染及web动画的性能问题,以及拜读《CSS SECRET》(CSS揭秘)这本大作。 本文主要想谈谈页面优化之滚动优化。 主要内容包括了为何需要优化滚动事件,滚动与页面渲染的关系,节流与防抖,pointer-events:none 优化滚动。 说教了一堆废话,不喜欢的直接忽略哈,回到正题,要找到优化的入口就要知道问题出在哪里,对于页面优化而言,那么我们就要知道页面的渲染原理: 浏览器渲染原理我在我上一篇文章里也要详细的讲到,不过更多的是从动画渲染的角度去讲的 :【Web动画】CSS3 3D 行星运转 && 浏览器渲染原理 。 通过元素分组,当某个层的内容改变时,我们只需要更新该层的结构,并仅仅重绘和栅格化渲染层结构里变化的那一部分,而无需完全重绘。
input type="radio" name="select" id="slide_4"> <input type="radio" name="select" id="slide_<em>5</em>" <label for="slide_4" class="slide slide_4"></label> <label for="slide_<em>5</em>" class="slide slide_<em>5</em>"></label>