在软件开发中，选择最有效的方法来解析大型数据集对于提高性能至关重要。我进行了一个实验，比较了使用 Node.js 统计大型文本文件中换行符数量的两种不同方法：使用 indexOf 和手动逐字节检查。
最近正在做一个基于浏览器 File Reader API 的文本解析工具。为了让繁重的文本解析工作不影响页面线程的性能，使用 Web Worker 来负责处理文本解析应该是最优的。Web Worker 需要将解析后的每行文本传回给页面，当需要传输的文本行数达到数十万、百万行时，性能问题就变得尤为重要，一方面是传输的耗时，一方面是内存的消耗。多数浏览器实现了结构克隆，允许你对 Web Worker 传入、传出更复杂的数据类型，如：File, Blob, ArrayBuffer, JSON 对象等。然而当你使用postMessage()方法传输这些数据时，数据会被拷贝一份再进行传输，所以当你传输 100MB 的数据时，主进程和 Worker 进程都会增加 100MB 的内存使用，并且复制 100MB 的数据需要的时间可能达到几百毫秒。为了解决这个问题，postMessage()方法也支持传输 Transferable 数据类型，使用 Transferable 传输时，会直接把数据从一个执行环境（Worker 线程或主线程）传输到另一个执行环境，这样不会额外增加一份内存消耗，并且传输速度极快因为不需要数据拷贝。可是在实际使用中，如果需要传输大量的 Transferable 数据时，这种方法仍存在显著的性能问题。
HTML5 的FileReader API 可以让客户端浏览器对用户本地文件进行读取，这样就不再需要上传文件由服务器进行读取了，这大大减轻了服务器的负担，也节省了上传文件所需要的时间。不过在实践中我发现用FileReader.readAsText()可以轻易地处理一个 300k 的日志文件，但当日志文件有 1G、甚至 2G 那么大，浏览器就会崩溃。这是因为readAsText()会一下子把目标文件加载至内存，导致内存超出上限。所以如果 Web 应用常常需要处理大文件时，我们应该使用FileReader.readAsArrayBuffer()来一块一块读取文件。
在绑定onscroll事件时，我们应当着重关注其性能问题，因为onscroll与其他的鼠标、键盘等事件相比，它被触发的频次很高，间隔很近。如果onscroll事件中涉及到大量的位置计算、元素重绘等工作且这些工作无法在下一个onscroll事件触发前完成，就会造成浏览器掉帧。加之用户鼠标滚动往往是连续的，就会持续触发onscroll事件导致掉帧扩大、浏览器CPU使用率增加、用户体验受到影响。由于开发人员的机器配置普遍都不错，可能同一个onscroll的事件在开发机上只需要10ms，然而在普通配置的机器上需要30ms，因此这类问题常会被开发人员忽视。这篇文章将介绍如何避免onscroll事件潜在的性能问题。
网页中引用的外部文件： JavaScritp、CSS 等常常会阻塞浏览器渲染页面。假设在 <head> 中引用的某个 JavaScript 文件由于各种不给力需要2秒来加载，那么浏览器渲染页面的过程就会被阻塞2秒，直到该JS文件下载并执行完后才继续。前端性能调优时必须排除任何潜在的渲染阻塞点，让浏览器在最短时间内渲染出整体页面。
当浏览器请求一个之前访问过的静态文件时，会在 HTTP 头中加上：If-Modified-Since、If-None-Match以向服务器确认该文件是否有更新，如果没有更新，服务器则返回 304 Not Modified，浏览器就会使用本地缓存而不是从服务器重新下载该文件。这是多数 Web Server 对于静态文件的默认缓存行为，然而这个缓存行为仍有优化空间。默认的缓存行为依然需要浏览器与服务器建立一个 HTTP 连接以确定每个文件是否更新过，从客户端建立连接、发送连接、服务器判断文件状态到最终客户端收到 304 Not Modified 之间仍需要几十甚至上百毫秒并且消耗一定的服务器资源。