查看详情

聊聊 Timing-Allow-Origin 和 Access-Control-Expose-Headers

一般我们如果做页面性能分析，我们自己带着 Chrome 的 PageSpeed 或者 Audit 就可以了。但是如果我们涉及对关键资源的网络请求的性能埋点的话，我们可以尝试利用 PerformanceTiming 。 它提供了诸如一系列 connectStart domainLookupStart responseEnd 等时间戳的数据。我们可以轻松借用这个 API 做页面的 Performance 的数据埋点。比如可以使用： const pt = performance.timing; const domReady = pt.domInteractive - pt.navigationStart //... 初次之外，我们可以利用 getEntries() 来筛选关键资源，比如你希望埋点的 JS 或者 CSS 资源又或者视频音频资源。 const resource = performance.getEntriesByType('resource'); resource.forEach((item) => { // handle your resource timing data 详情 »

查看详情

Web前端优化的关键词

忽然发现很多人都喜欢用这个问题来问，其实这个问题和 “输入url到网页出现发生了什么”类似，详见知乎上的讨论， 很多人都能回答上来，但是这个问题所能涉及到的知识点却非常多。 那么其实如果我们能够理解输入url都经历了什么，那么我们要做的优化点就是针对这个过程中的每个环节，虽然有些方面并不算前端范畴，但是也需要有所了解。 这个问题有人都已经回到到硬件，用户网络层面这里就忽略吧，我们直接从url解析开始； DNS查找 输入url会先经理一系列事情，前端不用负责这一块，都是浏览器自己做的，url会先找到对应的ip，如果有DNS缓存就快很多，如果没有呢，就不得不去搜索域名直到找到你的要去的域名。 服务器接受请求 服务器接收到数据请求的时候就需要响应并吐出数据。如果是一个静态页面，它就吐出写好的html代码，如果是服务端语言处理过，那部分还需要服务端工程师参与。所以呢，这个时候你有理由去质疑下是不是服务端工程师那边程序是不是出了问题。不过这个解决的事情也不是我们能够做的咯。 浏览器接受到html内容后 接下来，就是我们的事情咯。自己觉得优化一个字小一定不会错（错这个字是相对的，），“变小”。都知道吐出一个400kb的页面和10KB的页面，明显后者快，（在相同物理环境下）。所以变小的过程我们就可以大作文章。 优化其实来源支撑原有体系的每个细节 一个关键字，小。那么一个页面，我们自己写的自然就心里有数。JS + CSS + HTML。如果我们发觉我们把JS CSS都推挤在了html上，html上自然体积就大了。这个时候我们尝试用外链，这样html就会小很多。如果我们再把CSS 和 详情 »