从 Chrome 68 开始，service worker 脚本检查更新的HTTP请求将默认不受 HTTP cache 的影响。这可以解决开发人员的共同难题，即在 service worker 脚本上设置无意的 Cache-Control 标头可能导致的更新延迟。
Chrome V8 简称 V8，是由谷歌开源的一个高性能 JavaScript 引擎。该引擎采用 C++ 编写，Google Chrome 浏览器用的就是这个引擎。V8 可以单独运行，也可以嵌入 C++ 应用当中。
本地部署测试的时候，用火狐浏览器需要把 前端的 config.js 中的服务地址改成 http://localhost:8081
最近在开发者模式下调试 Chrome 插件，发现安装扩展后默认会报错误，提示 v2 版本已经废弃，相关 API 功能将在明年不可使用，建议升级到 v3 版本
本文主要讲述，关于 Chrome Content Download 时间过长问题调查经过，及相关优化方案
首先贴个Javascript性能测试站点，测试并展示了数个 JavaScript 引擎的性能数据：arewefastyet
很多人，包括我自己，初看Service Worker多一个Cache Storage的时候，就感觉跟HTTP长缓存没什么区别。 例如大家讲的最多的Service Worker能让网页离线使用，但熟悉HTTP缓存的朋友，会发现，把整站所有资源设置为长缓存（不带校验），也可以实现离线使用。 那么，Service Worker在缓存方面和HTTP缓存比较，有什么好处呢？ 带着这个疑问，我翻阅了一些大神博客 JakeArchibald的《Caching best practices & max-age gotc
一、了解Web Workers 介绍 js 的 Workers 前, 先思考什么是异步javascript? 为什么需要异步javascript的存在? 我们知道在编程模型上分为同步编程和异步编程:
在chrome[1]插件开发中我们知道，background.js是独立于浏览器的，在background.js中主要负责popup与content.js的交互,在某些时候，也许你需要在一个插件的设置页与content进行实时通信，此时你能想到什么样的方式吗？本文是在插件业务通信总结的一篇笔记，希望看完能在实际业务中带来思考和帮助
0x00 起因 不久前@三好学生师傅买了一个wooyun wifi,然后聊到了缓存投毒： 然后看到wooyun wifi的这个说明： 默认情况下该功能附带缓存投毒功能，将视图缓存所有的页面至2099年
本文我们继续来介绍nginx的实际操作，本文来介绍下Nginx的动静分离的实现。
PWA是最近前端最火热的一个概念之一，Service Worker为PWA赋能离线可用性以及push消息。
自苹果推出了iPhone应用商店以来，App成为了我们生活中不可或缺的一部分，而对于实体业务也是如此，现在各行业都在推出自己的App，但有没有人想过这样一种场景，如果自己的潜在客户还没有安装你的App亦或是即便安装但因为客户的手机存储空间紧张而卸载掉了你的App？那有没有使App更轻量，更易安装的技术实现呢？答案是“有的”。
性能优化不单指优化一个页面的打开速度，在开发环境将一个项目的启动时间缩短使开发体验更好也属于性能优化，大文件上传时为其添加分片上传、断点续传也属于性能优化。在项目开发以及用户使用的过程中，能够让任何一个链路快一点，都可以被叫做性能优化。
周末肛了一下0ctf，发现自己依旧那么菜。一道题也没解出来，成功的再一次拖了队伍后退。 今天发现国外大佬们已经开始放wp了。于是自己学习一波，复现一下。 先吐槽一波 h4x0rs.club1 Flag is biography of the administrator. There are more than one way to get this flag. h4x0rs.club-https://h4x0rs.club/game/ backend_www got backup at /var/www/h
渐进式Web应用程序需要使用HTTPS连接。虽然使用HTTPS会让您服务器的开销变多，但使用HTTPS可以让您的网站变得更安全，HTTPS网站在Google上的排名也会更靠前。
0x00 引言 首先声明，这不是一个新洞，看过 Homakov 文章（最后附）以及译文的人想必对这种漏洞有所了解。 但原文写的太过简单（没有说明利用条件、情景和特性），且译文和我的理解略有偏差，于是就有了这篇文章。 这种漏洞已经存在一段时间了，有没有被利用过尚不得知，虽然利用条件较苛刻，但是当符合条件的站点被攻击后， 影响面和影响程度巨大，并且普通用户不知如何清除, 可导致长期持续攻击。 2014年底的时候，这种漏洞的利用条件没有现在苛刻（比如没有Service-Worker-Allowed头），一年过来
编者按：本文作者高峰 http://verymuch.site/，奇舞团前端工程师，W3C性能工作组成员，同时在WOT工作组学习。
页面加载 首先，浏览器发起直接对目标html的请求，然后分析其中用到的资源并下载，浏览器有自己的规则来判断什么样的资源可以被并行下载，什么样的不可以，浏览器对加载顺序有着特殊的喜好： JS的出现会延迟后续CSS的下载，因为JS会改变页面元素，浏览器会延迟整个页面的渲染直到JS被下载解释并执行，所以必须让CSS的链接在JS前面以达到尽可能的并行。 与浏览器支持的并发连接数有关 在HTTP 1.1协议中要求浏览器访问同一host的连接数不得大于2，但事实上当前绝大多数浏览器都违背了这一要求，具体参见：并发连
导语 | Node.js内存泄漏的问题经常让开发者头疼，我们应该怎么样解决这类问题呢？本文通过一个V8引擎自身Bug导致Generator内存泄漏案例，来介绍常用的应对手段。 一、背景 最近新开发了一个Node.js服务，却发现上线之后内存一直持续上涨。相信很多使用Node.js做过服务端开发的同学，也遇到过这样的问题，这种情况就是典型的内存泄漏。内存泄漏虽然不会马上让应用停止服务，但是如果不处理的话，轻则会导致你的应用越来越慢，重则会导致应用Crash。所以对于这种情况，我们不能掉以轻心。 二、
WebAssembly + Emscripten, Web 组件 + Lit, Service Workers + Workbox，以及全新 Web API 在此汇聚。Chrome 和 Adobe 正在携手打造新的图像编辑体验。
原文：《Using JavaScript modules on the web》 https://developers.google.com/web/fundamentals/primers/modules 译者序 JS modules，即ES6的模块化特性，通过 <scripttype="modules">可以实现不经过打包直接在浏览器中import/export，此玩法确实让人眼前一亮。 先看看 <scripttype="modules">的兼容性。目前只有较新版本的chrome/firefox/saf
首先需要在服务器上建立一个文件，里面的内容确定了哪些文件需要缓存，哪些文件不需要，如果资源无法访问会使用什么页面等
本文为 Google Chrome 团队的开发项目工程师 Addy Osmani 在PerfMatters 2019 网页性能大会发表的“JavaScript性能优化”（https://medium.com/@addyosmani/the-cost-of-javascript-in-2018-7d8950fbb5d4）的演讲，其分享了处理 JavaScript 的脚本优化建议，大幅地减少了下载时间和执行时间。
字节码缓存（Bytecode Cache），是浏览器性能优化机制中重要的一项，通过缓存 解析（pasing）+编译（compilation）的结果，减少网站的启动时间；当前市面上主流的浏览器都实现了字节码缓存功能；
学前端这么久了，从一无所知到web网页的开发，自己也是踩了巨多的坑，自己也在不断的摸索中，短时间内可能不会再做前端了，毕竟java是我的主方向。总结一下web网站在性能提升方面前端能做些什么优化，其中有结合一些资料，也有自己的经验之谈，毕竟不是专门学前端的，有不对的地方敬请多多指教。
2、除了在插件内部contenscript background 和 popup之间传递消息以外，其他网站也可以给插件发送消息。方法如下 首先，需要增加配置 externally_connectable:{matches:[“https://*.xxx.com/”]}指定允许哪些网站可以给当前插件发送消息，相当于白名单，只有在白名单中的站点发送的消息，扩展才会监听
原文说的JS modules，实际上指的是ES6的模块化特性，通过<script type="module">可以实现不经过打包直接在浏览器中import/export，此玩法确实让人眼前一亮。
问题：在浏览器中输入URL到整个页面显示在用户面前时这个过程中到底发生了什么。仔细思考这个问题，发现确实很深，这个过程涉及到的东西很多。
很久之前就想关于浏览器渲染原理做一份总结性文章。之前也看过网上不少这个方面的文章，关于浏览器渲染机制的原理文章非常多但是总是觉得差那么一点意思，没有串联整个流程。所以这里打算串联这两部分，从原理和实践出发讲解他们背后的含义。
提起Chrome扩展插件(Chrome Extension)，每个人的浏览器中或多或少都安装了几个插件，像一键翻译、广告屏蔽、录屏等等，通过使用这些插件，可以有效的提高我们的工作效率；但有时候，我们想要的某个功能市面上没有现成的插件，作为开发者自然而然想到，自己是否可以动手开发一个定制化的插件？网上目前很多不错的关于Chrome插件的开发教程，可以帮助我们快速上手开发一个插件， 本文换个思路，从应用着手，通过讲解插件的特性来启发读者在工作中哪些场景可以通过插件来解决。
有没有好奇chrome[1]插件是用什么做的？像类似掘金插件又是怎么实现的，当我安装稀土掘金插件后，我的导航页都被改掉了，因此你也可以做一个类似的插件，来导航你公司的一些产品，方便快捷的实现你的内部导航
1 H5 缓存机制介绍 H5，即 HTML5，是新一代的 HTML 标准，加入很多新的特性。离线存储（也可称为缓存机制）是其中一个非常重要的特性。H5 引入的离线存储，这意味着 web 应用可进行缓存，并可在没有因特网连接时进行访问。 H5 应用程序缓存为应用带来三个优势： 离线浏览 用户可在应用离线时使用它们 速度 已缓存资源加载得更快 减少服务器负载 浏览器将只从服务器下载更新过或更改过的资源。 根据标准，到目前为止，H5 一共有6种缓存机制，有些是之前已有，有些是 H5 才新加入的。 浏览器缓存机制
install 事件回调中有两个方法： * event.waitUntil()：传入一个 Promise 为参数，等到该 Promise 为 resolve 状态为止。 * self.skipWaiting()：self 是当前 context 的 global 变量，执行该方法表示强制当前处在 waiting 状态的 Service Worker 进入 activate 状态。 * 安装后( installed )：Service Worker 已经完成了安装，并且等待其他的 Service Worker 线程被关闭。 * 激活( activating )：在这个状态下没有被其他的 Service Worker 控制的客户端，允许当前的 worker 完成安装，并且清除了其他的 worker 以及关联缓存的旧缓存资源，等待新的 Service Worker 线程被激活。
在前几天师夷长技以制夷:跟着PS学前端技术文件中，我们提到了WorkBox，然后自己也对这块很感兴趣，所以就利用业余时间进行相关资源的查询学习和实践。在学习过程中发现，想要弄明白WorkBox，有一点很关键，我们需要搞懂Service Worker。
【引子】前端可能是一个日新月异的领域，我们很难了解其中的方方面面。但是，前端系统一般都以浏览器作为运行环境， 对浏览器的进一步理解有助于我们更好地开发前端应用。这也是本文的由来之一，也作为对runtime的一次实例分析。
最近开源了一个 Vue 组件，还不够完善，欢迎大家来一起完善它，也希望大家能给个 star 支持一下，谢谢各位了。
本文首发于知乎，各位可以通过点击文章下方的阅读原来来访问原文地址 近日（6月3日），nodeJS的作者——Ry（Ryan Dahl）在JS Conf Berlin上做了一个题为 【10 THINGS
当我们在浏览器的地址栏输入 www.cnblogs.com ，然后回车，回车到看到页面到底发生了什么呢？ 域名解析 --> 发起TCP的3次握手 --> 建立TCP连接后发起http请求 --> 服务器响应http请求，浏览器得到html代码 --> 浏览器解析html代码，并请求html代码中的资源（如js、css、图片等） --> 浏览器对页面进行渲染呈现给用户 一、域名解析 首先Chrome浏览器会解析www.cnblogs.com这个域名对应的IP地址。怎么解析到对应的IP地址？ Chrome浏览器
网站性能监测与优化策略 0.引言 作为互联网项目，最重要的便是用户体验。在举国“互联网+”的热潮中，用户至上也已经被大多数企业所接收，特别是在如今移动端快速发展的时代，我们的网页不仅只是呈现在用户的PC浏览器里，更多的时候，用户是通过移动产品浏览我们的网页。加之有越来越多的开发者投入到Web APP和Hybrid APP的开发队伍中，性能，又再一次成为了被程序员们重点关注的话题。我曾经看到过这样一句话：一个网站的体验，决定了用户是否愿意去了解网站的功能；而网站的功能，决定了用户是否会一票否决网站的
Service Workers 是什么？它们能做什么，它如何让您的 web 应用更好的表现？本文旨在回答这些问题，以及如何使用 Ember.js 框架来实现 Service Worker。
Deno 是一个 JavaScript/TypeScript 的运行时，默认使用安全环境执行代码，有着卓越的开发体验。Deno 含有以下功能亮点：
众所周知，JavaScript 是单线程的语言。当我们面临需要大量计算的场景时（比如视频解码等），UI 线程就会被阻塞，甚至浏览器直接卡死。现在前端遇到大量计算的场景越来越多，为了有更好的体验，HTML5 中提出了 Web Worker 的概念。Web Worker 可以使脚本运行在新的线程中，它们独立于主线程，可以进行大量的计算活动，而不会影响主线程的 UI 渲染。当计算结束之后，它们可以把结果发送给主线程，从而形成了高效、良好的用户体验。Web Worker 是一个统称，具体可以细分为普通的 Worker、SharedWorker 和 ServiceWorker 等，接下来我们一一介绍其使用方法和适合的场景。
谷歌的数据表明，一个有 10 条数据 0.4 秒可以加载完的页面，在变成 30 条数据加载时间为 0.9 秒后，流量和广告收入减少了 20%。当谷歌地图的首页文件大小从 100kb 减少到 70~80kb 时，流量在第一周涨了 10%，接下来的三周涨了 25%。
目前，国内主流的前端应用框架具有两个：vue.js和react.js，关于vue和react的优劣性，网上众说纷纭。在下就不在此引战。
之前写的《webpack性能优化(0):webpack性能优化概况-优化构建速度》、《webpack性能优化(1):分隔/分包/异步加载+组件与路由懒加载》
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
即时通信 IM
