前端性能优化(三)——浏览器九大缓存方法

上一篇文章介绍的是《浏览器缓存机制》,浏览器缓存是浏览器保存数据用于快速读取或避免请求重复资源,提升网页加载速度。缓存的数据到底放哪了呢?作为开发者,有时也需要检查一下缓存中的内容。所以介绍下缓存方法以及缓存内容在哪查找?

1、http 缓存

http缓存是存在于服务器与浏览器之间,是一种保存资源副本并在下次请求时直接使用该副本的技术。web缓存发现请求资源已经被存储,它会拦截请求,返回资源副本,而不会去服务器重新请求资源。

具体的缓存设置,如何判断是否有缓存?等,上一篇文章以详细介绍,可点击《浏览器缓存机制》查看。

打开浏览器调试模式,在 Application 右侧就会有浏览器的 8 种缓存方式,具体如下:

前端性能优化(三)——浏览器九大缓存方法

2、websql

websql是较新的chrome浏览器支持,并以独立规范形式出现,引入了一组使用 SQL 操作客户端数据库的 APIs。websql主要特点:

  • Web Sql数据库 API 不是HTML5的一部分,在H5之前就已经存在了。
  • 将数据以数据库的形式存储在客户端,按需读取。
  • 数据便于检索,允许使用sql语句。
  • 可以使浏览器实现小型数据库存储功能。

websql常用的API如下:

openDatabase - 打开已存在的数据库,如果不存在,则会新建一个新的数据库。
transaction - 控制一个事物,以及这种情况执行提交或者回滚。
executeSql - 执行 SQL 语句。

3、indexDB

indexDB 是为了能够在客户端存储客观数量的结构化数据,并且在这些数据上使用索引进行高性能的检索。DOM存储对于少量数据是非常友好的,但不适合存储大量结构化数据,indexDB就是为了解决这个问题而生的。

indexDB 分别为同步和异步访问提供了单独的API,同步API本打算供Web Worker内部使用,但目前还未实现。异步API在Web Worker内部和外部都可以使用,另外浏览器对indexDB有50M大小限制。

indexDB主要特点有:

  • indexDB大小取决于你的硬盘,存储的数据量非常大。
  • 可以直接存储任何类型的数据,如 js任何类型的数据 、blob流。
  • 可以创建索引,提供高性能搜索功能。
  • 采用事务,保证数据的准确性和一致性。

4、cookie

cookie指的就是会话跟踪技术。一般指网站为了辨别用户身份,进行session跟踪而而存储在用户本地终端上的数据,cookie一般通过http请求头发送到服务器。cookie主要特点有:

  • 跨域限制,同一个域名下可多个网页内使用。
  • cookie可以设置有效期,超出有效期自动清除。
  • cookie存储大小在4K以内。
  • cookie的存储不能超过50个cookie。
  • 只能存储字符串类型。

cookie常用操作:

setMaxAge - 设置cookie的有效期,时间单位是秒,负值时表示关闭浏览器后就失效,默认值为-1。
setDomain - 用于指定,只有请求指定域名才会带上该cookie。
setPath - 只有访问该域名下的cookieDemo的这个路径地址才会带cookie。
setValue - 重置 value 。

5、localstorage

localStorage 是HTML5的一种新的本地缓存方案,目前使用比较多,一般存储ajax返回的数据,存储特点主要有:

  • 数据可以长久保存,没有有效期,直到手动删除为止。
  • 存储的数据量大,一般5M以内。
  • 存储的数据可以在同一个浏览器的多个窗口使用。
  • 存储的数据不会发送到服务器。

localStroage常用API如下:

localStorage.setItem(key,value) // 保存数据
localStorage.getItem(key) // 获取数据
localStorage.removeItem(key) // 删除单个数据
localStorage.clear() // 删除全部

6、sessionstorage

sessionStorage与上述localStroage类似,它的特点主要有:

  • 存储的数据在浏览器关闭后删除,与网页窗口具有相同的生命周期。
  • 可以存储的数据大小5M。
  • 存储的数据不会发送到服务器。

sessionStorage常用API如下:

sessionStorage.setItem(key,value) // 保存数据
sessionStorage.getItem(key) // 获取数据
sessionStorage.removeItem(key) // 删除单个数据
sessionStorage.clear() // 删除全部

7、application cache

application cache是离线缓存技术,将大部分的图片、js、css等资源放在mainfest文件配置中,页面打开时通过mainfest文件读取本地文件或请求服务器资源。通常用于静态页面的缓存。

application cache特点:

  • mainfest文件必须有变化时才会更新。
  • 一次必须更新mainfest文件中的所有文件才能生效。
  • 当网络断开时,可以继续访问页面。
  • 文件缓存到本地,不需要每次都从网络上请求。
  • 稳定性比较好,遇网络故障或服务器故障可以继续访问本地缓存。
  • 加载速度快,缓存资源为本地资源,因此加载速度较快。

8、cacheStorage

cacheStorage 表示 cache对象的存储。该接口提供 serviceWorker 或其他类型的工作线程或window范围访问的所有命名缓存的主目录。

CacheStorage常见方法:

  • CacheStorage.match() - 检查给定的 Request 对象是否是 CacheStorage 对象跟踪的 Cache 对象中的键,返回Promise
  • CacheStorage.has() - 返回一个 Promise,它解析为与 cacheName 相匹配的 Cache 对象。
  • CacheStorage.delete() - 删除cache对象
  • CacheStorage.keys() - 含有keys中字符串的任意一个,则返回一个promise对象。
  • cacheStorage.has() - 如果包含cache对象,则返回一个promise对象。

9、flash缓存

flash缓存也是页面通过js调用flash读写特定的磁盘目录,达到本地数据缓存的目的。这是要基于flash的,所以基本不用。

  • 1
    点赞
  • 11
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
NGOOS–极益开源公益平台是极益科技专门为公益组织开发的CMS平台,主要用于快速搭建一个网站,以及公益组织所需的常见功能。NGOOS基于世界顶级CMS——TYPO3搭建,但是大大降低了中国人使用TYPO3的门槛,提高了易用性,到手即所得。 前端 精美设计——整合Bootstrap,响应式设计,适合多种分辨率屏幕。 大图切换——大图展示更震撼。 背景视频——用动态视频替代大图展示,效果更佳。 新闻系统——转发到朋友圈可以轻松转发打赏了,还可以使用多种社交账户参与评论点赞。 图库模块——可用于活动项目介绍等 电子证书——给捐赠人颁发捐赠证书,可用于分享。同时还会将证书通过邮件发送到邮箱。 业务地图——展示你们的业务地理分布,自定义默认地图区域。 背景地图——将地图作为背景,展示联系地址 视频发布——HTML5视频发布,无需Flash插件,适配所有设备 友情链接——用于合作伙伴展示 百度统计——时刻掌握网站的访问情况 百度搜索——使用百度站内搜索 在线捐赠——微信和支付宝捐赠,默认金额可修改。 捐赠查询——按照渠道、时间、金额、名字查询捐赠到账情况。 全站检索——检索全站信息、资讯。 发票申请——申请捐赠发票,增加了税号字段。 社区评论——整合畅言社会化评论 编辑器 ——更换了百度编辑器,增加了远程获取图片、Word批量传图片功能,复制全文,快速传图 项目进展——几组数据说明你现在项目的成绩 大事记 ——以时间线的方式展示大事记,支持年份、更为方便 团队列表——展示整个团队 志愿者登记——招募更多的志愿者 404页面支持 社区分享——分享到各大社区网站 页面二维码——扫码用手机打开浏览 常见内容编辑示例: 管理员登录后,前台可以直接使用管理组件编辑内容 启用了多级缓存,访问速度极快。 文本效果 SEO,全局配置,分页配置,友好地址,例如关于我们是:http://url/aboutus/ 而不是 http://url/index.php?id=12312333] 公益网站建设指南——参照GTI透明指数和《基金会信息公布办法》,在相应的页面上都有说明文字,告诉用户这里放什么内容。 业务后台 站点配置:配置网站名称、SEO、LOGO、支付宝和微信账号、邮件系统等。 修改密码 新闻发布、视频图片发布、置顶,可手机发新闻。 捐款列表并导出EXCEL 导入捐赠信息,按照样例xls文件导入。 按文章查看打赏列表,并可导出EXCEL 查看发票申请并可导出EXCEL。 编辑账号信息。 多浏览器适配,Chorome IE Firefox Safari 多设备适配,适配电脑/平板/手机 总后台 树形网站结构 30种网站内容元素 栏目自定,布局自选 不能再强大的模板系统 丰富而精确的权限管理 回收站功能 无限编辑历史撤销恢复 扩展管理器 全库检索 清除全站缓存 生产与开发模式,生产模式开启后,速度飞快。 多浏览器适配,Chorome IE Firefox Safari 其它:TYPO3有上万的功能点,在强大的后台,需要你一一探索。 注意:源码需在PHP7.0以上的环境中才能运行。 源码更新日志: NGOOS极益开源公益平台v2.2 更新日志: 系统内核升级到TYPO3 9.5.14版本,全面支持PHP7。 新增ECharts图表能力,增强数据展示能力。 新增页面静态化功能。 新增志愿者活动签到打卡系统。 新增PDF报告功能。 新增应用案例功能功能。 增加企业捐赠抵扣税务计算器与个人捐赠抵扣税务计算器。
前端性能优化实践# 知识体系与小册格局 ## 写给读者 提起性能优化,大家现在脑海里第一时间会映射出什么内容呢? 可能是类似[“雅虎军规”](https://developer.yahoo.com/performance/rules.html?guccounter=1)和[《高性能 JavaScript》](https://book.douban.com/subject/5362856/)这样历久弥香的经典之作,也可能是搜索引擎聚合给你的一篇又一篇以性能优化为主题的个人或团队实践而来的“私货”。至少当我确定自己的研发方向、并接到第一个性能优化任务时,我做的第一件事是向搜索引擎求助,第二件事是买书,然后开始了摸着石头过河,前后花费了大量的时间和精力。我深感性能优化实在是前端知识树中特别的一环——当你需要学习前端框架时,文档和源码几乎可以告诉你所有问题的答案,当你需要学习 Git 时,你也可以找到放之四海皆准的实践方案。但性能优化却不一样,它好像只能是一个摸索的过程。 这个摸索的过程是痛苦的、漫长的,也是紧要的。因为在如今的互联网环境下,一个前端团队如果只把性能优化这个任务写在纸上,而不投入实践,它将缺失最基本的竞争力。 笔者写这本小册,是希望通过短短十数个章节的讲解,尽可能降低一些大家学习性能优化的成本。 一方面,这本小册为没有接触过性能优化的新同学建立起一个正确的前端性能优化的“世界观”,知道性能优化是什么、为什么、怎么做,从而使性能优化这件事情有迹可循,有路可走。这样在面试现场被问到性能优化层面的问题时,能够做到滔滔不绝、言之有物,而非像背书一样罗列干巴巴的知识点,最终淹没在茫茫的求职大军中。另一方面,小册可以为在职的工程师们提供一线团队已经实践过的“方法论”,知道什么场景下该做什么事情,最终在脑海中留下一张涵盖核心原理和实践的、可随时查阅并且高度可扩展的性能优化思路索引表。然后在今后的开发生活中可以去践行它,更进一步去挖掘它。把性能优化变作你前端工程师生涯的一门必修课,进而演化为自己研发方面的核心竞争力。 同时,相信大家可以明确这样一个学习观念:任何技术的掌握,都离不开一定比例的理论基础和实际操作的支撑。 具体到前端性能优化这件事情上,我认为它是 20% 的理论,加上至少 80% 的实践,甚至很多理论本身也都是我们在具体的业务场景中实践出来的。所以希望大家阅读本小册时,能够读到一些“书本之外的东西”——最好是一边读一边回忆自己既有的开发经历,尝试去留意哪些知识是已知的,哪些是未知的。 这样读完之后,就可以有的放矢地把这些知识转换为自己的项目实践——前端技术日新月异,性能方案永远都在更迭,所以一定要形成自己的学习思路。 建议每一位读者都带着“学了就要用”的心态去读这本小册。如果阅读结束,能够为你带来哪怕一个小小的开发习惯或者优化观念上的改变,这数小时的阅读时间就算没有白费。 ## 知识体系: 从一道面试题说起 在展开性能优化的话题之前,我想先抛出一个老生常谈的面试问题: > 从输入 URL 到页面加载完成,发生了什么? 这个问题非常重要,因为我们后续的内容都将以这个问题的答案为骨架展开。我希望正在阅读这本小册的各位可以在心里琢磨一下这个问题——无须你调动太多计算机的专业知识,只需要你用最快的速度在脑海中架构起这个抽象的过程——我们接下来所有的工作,就是围绕这个过程来做文章。 我们现在站在性能优化的角度,一起简单地复习一遍这个经典的过程:首先我们需要通过 DNS(域名解析系统)将 URL 解析为对应的 IP 地址,然后与这个 IP 地址确定的那台服务器建立起 TCP 网络连接,随后我们向服务端抛出我们的 HTTP 请求,服务端处理完我们的请求之后,把目标数据放在 HTTP 响应里返回给客户端,拿到响应数据的浏览器就可以开始走一个渲染的流程。渲染完毕,页面便呈现给了用户,并时刻等待响应用户的操作(如下图所示)。 ![](https://user-gold-cdn.xitu.io/2018/10/18/16685737b823244c?w=489&h=329&f=png&s=19023) 我们将这个过程切分为如下的过程片段: 1. DNS 解析 2. TCP 连接 3. HTTP 请求抛出 4. 服务端处理请求,HTTP 响应返回 5. 浏览器拿到响应数据,解析响应内容,把解析的结果展示给用户 大家谨记,我们任何一个用户端的产品,都需要把这 5 个过程滴水不漏地考虑到自己的性能优化方案内、反复权衡,从而打磨出用户满意的速度。 ## 从原理到实践:各个击破 我们接下来要做的事情,就是针对这五个过程进行分解,各个提问,各个击破。 具体来说,DNS 解析花时间,能不能尽量减少解析次数
前端性能优化实践# 知识体系与小册格局 ## 写给读者 提起性能优化,大家现在脑海里第一时间会映射出什么内容呢? 可能是类似[“雅虎军规”](https://developer.yahoo.com/performance/rules.html?guccounter=1)和[《高性能 JavaScript》](https://book.douban.com/subject/5362856/)这样历久弥香的经典之作,也可能是搜索引擎聚合给你的一篇又一篇以性能优化为主题的个人或团队实践而来的“私货”。至少当我确定自己的研发方向、并接到第一个性能优化任务时,我做的第一件事是向搜索引擎求助,第二件事是买书,然后开始了摸着石头过河,前后花费了大量的时间和精力。我深感性能优化实在是前端知识树中特别的一环——当你需要学习前端框架时,文档和源码几乎可以告诉你所有问题的答案,当你需要学习 Git 时,你也可以找到放之四海皆准的实践方案。但性能优化却不一样,它好像只能是一个摸索的过程。 这个摸索的过程是痛苦的、漫长的,也是紧要的。因为在如今的互联网环境下,一个前端团队如果只把性能优化这个任务写在纸上,而不投入实践,它将缺失最基本的竞争力。 笔者写这本小册,是希望通过短短十数个章节的讲解,尽可能降低一些大家学习性能优化的成本。 一方面,这本小册为没有接触过性能优化的新同学建立起一个正确的前端性能优化的“世界观”,知道性能优化是什么、为什么、怎么做,从而使性能优化这件事情有迹可循,有路可走。这样在面试现场被问到性能优化层面的问题时,能够做到滔滔不绝、言之有物,而非像背书一样罗列干巴巴的知识点,最终淹没在茫茫的求职大军中。另一方面,小册可以为在职的工程师们提供一线团队已经实践过的“方法论”,知道什么场景下该做什么事情,最终在脑海中留下一张涵盖核心原理和实践的、可随时查阅并且高度可扩展的性能优化思路索引表。然后在今后的开发生活中可以去践行它,更进一步去挖掘它。把性能优化变作你前端工程师生涯的一门必修课,进而演化为自己研发方面的核心竞争力。 同时,相信大家可以明确这样一个学习观念:任何技术的掌握,都离不开一定比例的理论基础和实际操作的支撑。 具体到前端性能优化这件事情上,我认为它是 20% 的理论,加上至少 80% 的实践,甚至很多理论本身也都是我们在具体的业务场景中实践出来的。所以希望大家阅读本小册时,能够读到一些“书本之外的东西”——最好是一边读一边回忆自己既有的开发经历,尝试去留意哪些知识是已知的,哪些是未知的。 这样读完之后,就可以有的放矢地把这些知识转换为自己的项目实践——前端技术日新月异,性能方案永远都在更迭,所以一定要形成自己的学习思路。 建议每一位读者都带着“学了就要用”的心态去读这本小册。如果阅读结束,能够为你带来哪怕一个小小的开发习惯或者优化观念上的改变,这数小时的阅读时间就算没有白费。 ## 知识体系: 从一道面试题说起 在展开性能优化的话题之前,我想先抛出一个老生常谈的面试问题: > 从输入 URL 到页面加载完成,发生了什么? 这个问题非常重要,因为我们后续的内容都将以这个问题的答案为骨架展开。我希望正在阅读这本小册的各位可以在心里琢磨一下这个问题——无须你调动太多计算机的专业知识,只需要你用最快的速度在脑海中架构起这个抽象的过程——我们接下来所有的工作,就是围绕这个过程来做文章。 我们现在站在性能优化的角度,一起简单地复习一遍这个经典的过程:首先我们需要通过 DNS(域名解析系统)将 URL 解析为对应的 IP 地址,然后与这个 IP 地址确定的那台服务器建立起 TCP 网络连接,随后我们向服务端抛出我们的 HTTP 请求,服务端处理完我们的请求之后,把目标数据放在 HTTP 响应里返回给客户端,拿到响应数据的浏览器就可以开始走一个渲染的流程。渲染完毕,页面便呈现给了用户,并时刻等待响应用户的操作(如下图所示)。 ![](https://user-gold-cdn.xitu.io/2018/10/18/16685737b823244c?w=489&h=329&f=png&s=19023) 我们将这个过程切分为如下的过程片段: 1. DNS 解析 2. TCP 连接 3. HTTP 请求抛出 4. 服务端处理请求,HTTP 响应返回 5. 浏览器拿到响应数据,解析响应内容,把解析的结果展示给用户 大家谨记,我们任何一个用户端的产品,都需要把这 5 个过程滴水不漏地考虑到自己的性能优化方案内、反复权衡,从而打磨出用户满意的速度。 ## 从原理到实践:各个击破 我们接下来要做的事情,就是针对这五个过程进行分解,各个提问,各个击破。 具体来说,DNS 解析花时间,能不能尽量减少解析次数
很高兴为您介绍Spark性能优化指南——高级篇。 1. 数据倾斜问题 数据倾斜是指在Spark任务中,某些分区的数据量远远大于其他分区,导致任务执行时间过长。解决数据倾斜问题的方法包括: - 使用随机前缀或哈希分桶等方式对数据进行分区,使数据分布更加均匀。 - 对于reduceByKey等聚合操作,使用combineByKey或aggregateByKey等方法,避免数据倾斜。 - 对于join操作,使用broadcast变量或者将小表缓存到内存中,避免数据倾斜。 2. 内存管理 Spark的内存管理对于任务的性能有着重要的影响。以下是一些内存管理的优化方法: - 调整executor内存分配比例,避免OOM错误。 - 合理设置内存管理参数,如spark.memory.fraction、spark.memory.storageFraction等。 - 使用持久化存储,如cache或persist方法,避免重复计算和数据丢失。 3. 磁盘IO 磁盘IO是Spark任务中的瓶颈之一。以下是一些优化磁盘IO的方法: - 使用本地磁盘而非网络磁盘,避免网络IO带来的延迟。 - 使用压缩算法,如Snappy或LZ4,减少磁盘IO的数据量。 - 对于shuffle操作,使用Tungsten排序等优化算法,减少磁盘IO的次数。 4. 并行度 并行度是指任务中可以同时执行的任务数。以下是一些优化并行度的方法: - 调整任务的并行度,使任务能够充分利用集群资源。 - 对于shuffle操作,调整reduce任务的数量,避免过多的reduce任务导致性能下降。 - 对于数据量较大的任务,使用分区并行执行,避免单个任务的执行时间过长。 5. 网络传输 网络传输是Spark任务中的另一个瓶颈。以下是一些优化网络传输的方法: - 调整网络传输的缓存大小,使数据传输更加高效。 - 使用序列化算法,如Kryo或Java序列化,减少网络传输的数据量。 - 对于shuffle操作,使用Tungsten排序等优化算法,减少网络传输的数据量。 希望以上内容能够帮助您更好地优化Spark任务的性能。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

前端人

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值