摘要：從現(xiàn)狀談及性能優(yōu)化原文出處性能優(yōu)化指南如今網(wǎng)絡(luò)發(fā)展迅猛，這對(duì)我們構(gòu)建的互聯(lián)網(wǎng)平臺(tái)要求也更高。這就說明，我們?cè)陂_發(fā)時(shí)，并沒有站在用戶的角度上換位思考，更別談性能優(yōu)化。因此，我們可通過區(qū)分關(guān)鍵資源并調(diào)整加載的優(yōu)先級(jí)來實(shí)現(xiàn)性能優(yōu)化。

原文出處：《Karolina Szczur: The State of the Web》

性能優(yōu)化指南
The Internet is growing exponentially, and so is the Web platform we create. Often though we fail to reflect on the greater picture of connectivity and contexts the audience of our work might find themselves in. Even a short glance at the state of the World Wide Web shows that we haven’t been building with empathy, situation variability awareness, let alone performance in mind.
如今網(wǎng)絡(luò)發(fā)展迅猛，這對(duì)我們構(gòu)建的互聯(lián)網(wǎng)平臺(tái)要求也更高。而我們卻疲于反思用戶與我們之間的聯(lián)系。這就說明，我們?cè)陂_發(fā)時(shí)，并沒有站在用戶的角度上換位思考，更別談性能優(yōu)化。

So, what is the state of the Web today?
那么，互聯(lián)網(wǎng)現(xiàn)狀如何？

Only 46% of 7.4 billion people on this planet have access to the Internet. The average network speed caps at unimpressive 7Mb/s. More importantly, 93% of Internet users are going online through mobile devices?—?it becomes inexcusable to not cater to handhelds. Often data is more expensive than we’d assume?—?it could take anywhere from an hour to 13 hours to purchase 500MB packet (Germany versus Brazil; for more intriguing stats on connectivity head to Ben Schwarz’s Beyond the Bubble: The Real World Performance).
據(jù)統(tǒng)計(jì)，全球只有3億多人能接觸到互聯(lián)網(wǎng)，但網(wǎng)速平均只有7mb/s，關(guān)鍵的是，其中3億是通過移動(dòng)端瀏覽。勢(shì)必，我們開發(fā)時(shí)必須考慮這部分人群的需求。而且，數(shù)據(jù)也比我們想象中的要貴，有數(shù)據(jù)指出，我們可以在1-13個(gè)小時(shí)內(nèi)就花掉500MB流量（參考德國(guó)和巴西----想要更多關(guān)于用戶與互聯(lián)網(wǎng)之間聯(lián)系的有趣統(tǒng)計(jì)，可以看：https://building.calibreapp.c...）。

Our websites aren’t in a perfect shape either?—?the average site is the size of original Doom game (approx. 3 MB) (please note that for statistical accuracy medians should be used, read Ilya Grigorik’s excellent The “Average Page” is a myth. Median site size is currently at 1.4MB). Images can easily account for 1.7 MB of bandwidth and JavaScript averages at 400KB. This isn’t a problem specific to the Web platform only. Native applications aren’t better; remember that time you had to download 200 MB to get unspecified bug fixes?
而且，我們搭建的網(wǎng)站也并不完善——平均一個(gè)網(wǎng)站（計(jì)算首屏加載）的大小和國(guó)外經(jīng)典桌面游戲Doom game1的大小差不多（大約3MB）(注意這里計(jì)算出的平均值，參考Ilya Grigorik’s excellent The “Average Page” is a myth，目前一般網(wǎng)站首屏加載大約要1.4MB)，其中加載圖片需要1.7MB，javascript需要400KB。不僅在pc端有這個(gè)問題，手機(jī)原生應(yīng)用也好不到哪去，還記得你必須花200MB流量來更新app修復(fù)未知缺陷嗎？

As technologists often we find ourselves in the position of privilege. With up-to-date, high-end laptops, phones and fast cable Internet connection, it becomes all to easy to forget this isn’t the case for everyone (actually, it’s true for very few).
If we’re building the web platform from the standpoint of privilege and lack of empathy, it results in exclusionary, subpar experiences.
How can we do better by designing and developing with performance in mind?
作為技術(shù)人員，我們擁有絕對(duì)的優(yōu)勢(shì)。用最新、高配置的電腦和手機(jī)，網(wǎng)速也超快，這讓我們很容易認(rèn)為普羅大眾也是這樣（事實(shí)上，是很少很少）。
構(gòu)建網(wǎng)絡(luò)平臺(tái)時(shí)，如果我們安于開發(fā)特權(quán)、缺乏用戶同理心，將會(huì)導(dǎo)致極糟的用戶體驗(yàn)。
那么，在設(shè)計(jì)和開發(fā)時(shí)，怎樣才能做到性能優(yōu)化呢？

Optimising all assets
One of the most powerful, but under-utilised ways to significantly improve performance starts with understanding how the browser analyses and serves assets. It turns out that browsers are pretty great at discovering resources while parsing and determining their priority on the fly. Here’s where the critical request comes in.
A request is critical if it contains assets that are necessary to render the content within the users’ viewport.
For most sites, it’d be HTML, necessary CSS, a logo, a web font and maybe an image. It turns out that in many cases, dozens of other, irrelevant at the time assets are requested instead (JavaScript, tracking codes, ads, etc.). Luckily, we’re able to control this behaviour by carefully picking crucial resources and adjusting their priority.
要想顯著地提升性能，最有效但也容易被忽視的方法就是了解瀏覽器如何解析資源。已被證明，瀏覽器善于查找資源并且解析后快速確定資源加載的優(yōu)先級(jí)順序。那么什么資源優(yōu)先級(jí)高呢？這里有關(guān)于critical request的來源：
判斷一個(gè)請(qǐng)求是關(guān)鍵性請(qǐng)求，就看它是否包含用于渲染用戶可見內(nèi)容的資源
對(duì)于大多數(shù)網(wǎng)站來說，關(guān)鍵性請(qǐng)求是請(qǐng)求html文件、必要的css、logo、字體文件和圖片，在加載完這些文件后，再選擇加載其它非決定性的文件（JavaScript、統(tǒng)計(jì)代碼、廣告...）。因此，我們可通過區(qū)分關(guān)鍵資源并調(diào)整加載的優(yōu)先級(jí)來實(shí)現(xiàn)性能優(yōu)化。

With we’re able to manually force assets’ priority to High ensuring that desired content will be rendered on time. This technique can yield significant improvements in Time to Interactive metric, making optimal user experience possible.
方法一：為link標(biāo)簽設(shè)置rel="preload"屬性，手動(dòng)設(shè)置該資源優(yōu)先加載，來確保所期望的內(nèi)容及時(shí)呈現(xiàn)。這種技術(shù)可以顯著改善“交互時(shí)間”，使最佳用戶體驗(yàn)成為可能。

Critical requests still seem like a black box for many, and the lack of shareable materials doesn’t help to change that. Fortunately, Ben Schwarz published an incredibly comprehensive and approachable article on the subject?—?The Critical Request. Additionally, check Addy’s Preload, Prefetch and Priorities in Chrome.
關(guān)鍵性請(qǐng)求對(duì)于大多數(shù)人來說似乎還是個(gè)盲區(qū)，可共享資源的缺乏也沒有改變這一點(diǎn)。幸好，本·施瓦茨（Ben Schwarz）發(fā)表了一篇關(guān)于關(guān)鍵性請(qǐng)求的文章，文章非常全面且易懂。另外，Addy也有一篇文章《在Chrome中的預(yù)加載，預(yù)取和優(yōu)先級(jí)》。

General performance checklist

Cache aggressively

Enable compression

Prioritise critical assets

Use content delivery networks

積極地使用緩存

使用壓縮

優(yōu)先加載關(guān)鍵性請(qǐng)求

使用內(nèi)容傳送網(wǎng)絡(luò)CDN

Optimising images
Images often account for most of a web page’s transferred payload, which is why imagery optimisation can yield the biggest performance improvements. There are many existing strategies and tools to aid us in removing extra bytes, but the first question to ask is: “Is this image essential to convey the message and effect I’m after?”. If it’s possible to eliminate it, not only we’re saving bandwidth, but also requests.
圖片通常占網(wǎng)頁傳輸?shù)拇蟛糠钟行лd荷，因此圖片優(yōu)化可以帶來最大的性能提升。有許多現(xiàn)有的策略和工具可以幫助我們刪除額外的字節(jié)，但我們要考慮的第一個(gè)問題是：“這張圖片對(duì)于傳達(dá)我的信息和效果是否至關(guān)重要”。做好了圖片優(yōu)化，可以為用戶節(jié)省很多帶寬。

In some cases, similar results can be achieved with different technologies. CSS has a range of properties for art direction, such as shadows, gradients, animations or shapes allowing us to swap assets for appropriately styled DOM elements.
在某些情況下，不一定非得用圖片，可以通過不同的代碼方式實(shí)現(xiàn)相同的效果。CSS具有一系列屬性設(shè)置藝術(shù)樣式，例如陰影，漸變，動(dòng)畫或形狀，這些屬性可以把資源轉(zhuǎn)換為適當(dāng)風(fēng)格的DOM元素。

Choosing the right format
If it’s not possible to remove an asset, it’s important to determine what format will be appropriate. The initial choice falls between vector and raster graphics:
如果不可能刪除資源，確定哪種合適的格式很重要。首選矢量圖或柵格圖：

Vector: resolution independent, usually significantly smaller in size. Perfect for logos, iconography and simple assets comprising of basic shapes (lines, polygons, circles and points).
Raster: offers much more detailed results. Ideal for photographs.
矢量：分辨率獨(dú)立，通常尺寸很小。適用于logo，icon和一些由基本形狀（線，多邊形，圓和點(diǎn)）組成的圖片。
柵格：提供更細(xì)節(jié)的處理。更適用于圖片。

After making this decision, there are a fair bit of formats to choose from: JPEG, GIF, PNG–8, PNG–24, or newest formats such as WEBP or JPEG-XR. With such an abundance of options, how do we ensure we’re picking the right one? Here’s a basic way of finding the best format to go with:

JPEG: imagery with many colours (e.g. photos)

PNG–8: imagery with a few colours

PNG–24: imagery with partial transparency

GIF: animated imagery
決定好之后，我們可以選擇幾種格式：JPEG, GIF, PNG–8, PNG–24，或最新格式，如WEBP或JPEG-XR。有了這么多的選擇，我們?nèi)绾未_保我們選擇了合適的格式？這是找到最佳格式的基本方法：

JPEG：具有多種顏色的圖像（例如照片）

PNG-8：具有幾種顏色的圖像

PNG-24：具有部分透明度的圖像

GIF: 動(dòng)圖

Photoshop can optimise each of these on export through various settings such as decreasing quality, reducing noise or number of colours. Ensure that designers are aware of performance practices and can prepare the right type of asset with the right optimisation presets. If you’d like to know more how to develop images, head to Lara Hogan’s invaluable Designing for Performance.
Photoshop可以通過各種設(shè)置，例如降低畫質(zhì)，降低噪點(diǎn)或減少顏色數(shù)量來優(yōu)化圖片。確保設(shè)計(jì)師了解性能實(shí)踐，并可以使用正確的優(yōu)化方式來提供恰當(dāng)格式的資源。如果您想了解如何優(yōu)化圖片，請(qǐng)前往Lara Hogan’s invaluable Designing for Performance。

Experimenting with new formats
There are a few newer players in the spectrum of image formats, namely WebP, JPEG 2000 and JPEG-XR. All of them are developed by browser vendors: WebP by Google, JPEG 2000 by Apple and JPEG-XR by Microsoft.
圖像格式有幾個(gè)較新的玩家，即WebP，JPEG 2000和JPEG-XR。所有這些都是由瀏覽器供應(yīng)商開發(fā)的：Google的WebP，Apple的JPEG 2000和Microsoft的JPEG-XR。

WebP is easily the most popular contender, supporting both lossless and lossy compression, which makes it incredibly versatile. Lossless WebP is 26% smaller than PNGs and 25–34% smaller than JPGs. With 74% browser support it can safely be used with fallback, introducing up to 1/3 savings in transferred bytes. JPGs and PNGs can be converted to WebP in Photoshop and other image processing apps as well as through command line interfaces (brew install webp).
WebP是最受歡迎的競(jìng)爭(zhēng)者，支持無損和失真壓縮，這使得它非常通用。無損WebP比PNG小26％，比JPG小25-34％。有了74％的瀏覽器支持，它可以安全地用于回退，最多可節(jié)省1/3的傳輸字節(jié)。JPG和PNG圖片可以在Photoshop或其他圖像處理應(yīng)用程序以及命令行界面（brew install webp）中轉(zhuǎn)換為WebP。

If you’d like to explore (minor) visual differences between these formats I recommend this nifty demo on Github.
如果你想探索這些格式之間的視覺差異，我建議看看這個(gè)在Github上的demo。

Optimising with tools and algorithms
Even using incredibly efficient image formats doesn’t warrant skipping post-processing optimisation. This step is crucial.
即使使用高效的圖像格式也不值得跳過后處理優(yōu)化。這一步很重要。

If you’ve chosen SVGs, which are usually relatively small in size, they too have to be compressed. SVGO is a command line tool that can swiftly optimise SVGs through stripping unnecessary metadata. Alternatively, use SVGOMG by Jake Archibald if you prefer a web interface or are limited by your operating system. Because SVG is an XML-based format, it can also be subject to GZIP compression on the server side.
如果你選擇了通常尺寸相對(duì)較小的SVG，那么也需要被壓縮。SVGO是一個(gè)命令行工具，可以通過剝離不必要的元數(shù)據(jù)來快速優(yōu)化SVG?；蛘撸绻阆矚gWeb界面或受操作系統(tǒng)的限制，請(qǐng)使用Jake Archibald的SVGOMG。因?yàn)镾VG是基于XML的格式，它也可以在服務(wù)器端進(jìn)行GZIP壓縮。

ImageOptim is an excellent choice for most of the other image types. Comprising of pngcrush, pngquant, MozJPEG, Google Zopfli and more, it bundles a bunch of great tools in a comprehensive, Open Source package. Available as a Mac OS app, command line interface and Sketch plugin, ImageOptim can be easily implemented into an existing workflow. For those on Linux or Windows, most of the CLIs ImageOptim relies on can be used on your platform.
ImageOptim是大多數(shù)其他圖像類型的絕佳選擇。包括pngcrush，pngquant，MozJPEG，Google Zopfli等，它在一個(gè)開源包中捆綁了一堆很棒的工具。作為Mac OS應(yīng)用程序，命令行界面和Sketch插件，ImageOptim可以輕松地應(yīng)用到現(xiàn)有的工作流程中。對(duì)于那些在Linux或Windows上，大多數(shù)ImageOptim的CLI也可以使用。

If you’re inclined to try emerging encoders, earlier this year, Google released Guetzli?—?an Open Source algorithm stemming from their learnings with WebP and Zopfli. Guetzli is supposed to produce up to 35% smaller JPEGs than any other available method of compression. The only downside: slow processing times (a minute of CPU per megapixel).
如果你想嘗試新興的編碼器，Google今年早些時(shí)候發(fā)布了Guetzli - 源自WebP和Zopfli的開源算法。 Guetzli應(yīng)該比任何其他可用的壓縮方法產(chǎn)生比35％更小的JPEG。唯一的缺點(diǎn)：處理時(shí)間慢（CPU每百萬像素一分鐘）。

When choosing tools make sure they produce desired results and fit into teams’ workflow. Ideally, automate the process of optimisation, so no imagery slips through the cracks unoptimised.
選擇工具時(shí)，請(qǐng)確保它們適合項(xiàng)目和團(tuán)隊(duì)的工作流程。理想情況下，構(gòu)建自動(dòng)化優(yōu)化，這樣可以基本覆蓋所有需優(yōu)化的圖片。

Responsible and responsive imagery
A decade ago we might have gotten away with one resolution to serve all, but the landscape of ever-changing, responsive web is very different today. That’s why we have to take extra care in implementing visual resources we’ve so carefully optimised and ensuring they cater for the variety of viewports and devices. Fortunately, thanks to Responsive Images Community Group we’re perfectly equipped to do so with picture element and srcset attribute (both have 85%+ support).
十年前，我們可能已經(jīng)拋棄了一次性解決所有問題的觀念，如今的不斷發(fā)展的響應(yīng)式網(wǎng)絡(luò)更需如此。這就是為什么我們?cè)阡秩疚覀兙膬?yōu)化過的視覺資源時(shí)必須特別小心，并確保它們適應(yīng)各種視口和設(shè)備。幸運(yùn)的是，感謝Responsive Images社區(qū)小組，我們完全可以使用圖片元素和srcset屬性（都有85％+支持）。

The srcset attribute
Srcset works best in the resolution switching scenario—when we want to display imagery based on users’ screen density and size. Based on a set of predefined rules in srcset and sizes attributes the browser will pick the best image to serve accordingly to the viewport. This technique can bring great bandwidth and request savings, especially for the mobile audience.
Srcset在分辨率切換方案中效果最佳 - 當(dāng)我們要根據(jù)用戶的屏幕分辨率和大小顯示圖像時(shí)?；趕rcset和size屬性中的一組預(yù)定義規(guī)則，瀏覽器將選擇最佳圖像，以便相應(yīng)地提供給視口。這種技術(shù)可以帶來很大的帶寬，需謹(jǐn)慎使用，特別是針對(duì)移動(dòng)用戶。

The picture element
Picture element and the media attribute are designed to make art direction easy. By providing different sources for varying conditions (tested via media-queries), we’re able always able to keep the most important elements of imagery in the spotlight, no matter the resolution.
圖片元素和媒體屬性旨在使藝術(shù)化變得簡(jiǎn)單。通過為不同場(chǎng)景提供不同資源（通過媒體查詢測(cè)試），無論場(chǎng)景怎么變化，我們始終可以展現(xiàn)正確的圖像。

Make sure to read Jason Grigsby’s Responsive Images 101 guide for a thorough explanation of both approaches.

務(wù)必閱讀Jason Grigsby的Responsive Images 101指南，以便徹底理解這兩種方法。

Delivery with image CDNs
The last step of our journey to performant visuals is delivery. All assets can benefit from using a content delivery network, but there are specific tools targeting imagery, such as Cloudinary or imgx. The benefit of using those services goes further than reducing traffic on your servers and significantly decreasing response latency.
圖片優(yōu)化的最后一步是傳輸。所有資源可以放到CDN上，現(xiàn)有一些特定的工具可以定位到圖像，例如“Cloudinary”或“imgx”。使用這些服務(wù)的好處遠(yuǎn)遠(yuǎn)超過想辦法減少服務(wù)器上的流量，并顯著降低了響應(yīng)延遲，提升加載速度。

CDNs can take out a lot of complexity from serving responsive, optimised assets on image-heavy sites. The offerings differ (and so does the pricing) but most handle resizing, cropping and determining which format is best to serve to your customers based on devices and browsers. Even more than that?—?they compress, detect pixel density, watermark, recognise faces and allow post-processing. With these powerful features and ability to append parameters to URLs serving user-centric imagery becomes a breeze.
CDN在圖像重磅的網(wǎng)站上響應(yīng)和優(yōu)化資源會(huì)加重復(fù)雜度。資源不同（花費(fèi)也是如此），但是大多數(shù)處理器可以根據(jù)設(shè)備和瀏覽器調(diào)整合適的大小，裁剪并確定最合適的格式。而且 - 它們可以進(jìn)行壓縮，檢測(cè)像素密度，水印，識(shí)別面部并允許后處理。借助這些強(qiáng)大的功能和將參數(shù)附加到以用戶為中心的圖像的URL的功能變得輕而易舉。

Image performance checklist

Choose the right format

Use vector wherever possible

Reduce the quality if change is unnoticeable

Experiment with new formats

Optimise with tools and algorithms

Learn about srcset and picture

Use an image CDN

選擇正確的格式

盡可能使用矢量

如果變化不明顯，則降低畫質(zhì)

嘗試新格式

用工具和算法進(jìn)行圖片優(yōu)化

了解srcset和圖片元素

圖片放到CDN

Optimising web fonts
The ability to use custom fonts is an incredibly powerful design tool. But with power comes a lot of responsibility. With whooping 68% of websites leveraging web fonts this type of asset is one of the biggest performance offenders (easily averaging 100KB, depending on the number of variants and typefaces).
使用自定義字體的是一個(gè)非常強(qiáng)大進(jìn)步。但權(quán)力越多責(zé)任越大。有68％的網(wǎng)站利用網(wǎng)絡(luò)字體，這種類型的資產(chǎn)是最大的性能違規(guī)者之一（容易平均100KB，取決于變體和字體的數(shù)量）。

Even when weight isn’t the most major issue, Flash of Invisible Text (FOIT) is. FOIT occurs when web fonts are still loading or failed to be fetched, which results in an empty page and thus, inaccessible content. It might be worth it to carefully examine whether we need web fonts in the first place. If so, there are a few strategies to help us mitigate the negative effect on performance.
即使重量不是最大的問題，Flash的隱形文本（FOIT）也是。當(dāng)網(wǎng)頁字體在加載中或未能被抓取時(shí)，會(huì)發(fā)生FOIT，這會(huì)導(dǎo)致空白頁面，從而導(dǎo)致無法訪問的內(nèi)容。首先要仔細(xì)檢查我們是否需要網(wǎng)頁字體。如果是這樣，有一些策略可以幫助我們減輕對(duì)性能方面的負(fù)面影響。

Choosing the right format
There are four web font formats: EOT, TTF, WOFF and more recent WOFF2. TTF and WOFF are most widely adopted, boasting over 90% browser support. Depending on the support you’re targeting it’s most likely safe to serve WOFF2 and fall back to WOFF for older browsers. The advantage of using WOFF2 is a set of custom preprocessing and compression algorithms (like Brotli) resulting in approx. 30% file-size reduction and improved parsing capabilities.
有四種網(wǎng)絡(luò)字體格式：EOT，TTF，WOFF和近期的WOFF2。 TTF和WOFF被廣泛采用，擁有超過90％的瀏覽器支持。根據(jù)你的項(xiàng)目，盡可能穩(wěn)定地支持WOFF2，并在舊版瀏覽器上使用WOFF。使用WOFF2的優(yōu)點(diǎn)是其有一套定制的預(yù)處理和壓縮算法（如Brotli），能縮小大約30％的文件大小和提升解析功能。

When defining the sources of web fonts in @font-face use the format() hint to specify which format should be utilised.
在@font-face中定義網(wǎng)頁字體的來源時(shí)，請(qǐng)使用format()來指定應(yīng)使用哪種格式。

If you’re using Google Fonts or Typekit to serve your fonts, both of these tools have implemented a few strategies to mitigate their performance footprint. Typekit now serves all kits asynchronously, preventing FOIT as well as allows for extended cache period of 10 days for their JavaScript kit code (instead of default 10 minutes). Google Fonts automatically serves the smallest file, based on the capabilities of the users’ device.
如果你使用Google Fonts或Typekit來作為字體，這兩種字體都實(shí)施了一些策略來減輕其性能消耗。 Typekit現(xiàn)在可以異步地為所有工具包提供服務(wù)，保護(hù)FOIT以及允許其JavaScript代碼延長(zhǎng)10天的緩存時(shí)間（而不是默認(rèn)10分鐘）。 Google Fonts可以根據(jù)用戶設(shè)備的性能自動(dòng)提供最小的文件。

Audit font selection
No matter whether self-hosting or not, the number of typefaces, font weights and styles will significantly affect your performance budgets.
無論是否自主托管，字體數(shù)量、大小和樣式都將顯著影響你的性能預(yù)算。

Ideally, we can get away with one typeface featuring normal and bold stylistic variants. If you’re not sure how to make font selection choices refer to Lara Hogan’s Weighing Aesthetics and Performance.
理想情況下，我們可以避免使用正?；蚣哟指袷缴献凅w的字體。如果不確定如何選擇字體，請(qǐng)參考Lara Hogan的衡量美與性能。

Use Unicode-range subsetting
Unicode-range subsetting allows splitting large fonts into smaller sets. It’s a relatively advanced strategy but might bring significant savings especially when targeting Asian languages (did you know Chinese fonts average at 20,000 glyphs?). The first step is to limit the font to the necessary language set, such as Latin, Greek or Cyrillic. If a web font is required only for logotype usage, it’s worth it to use Unicode-range descriptor to pick specific characters.
Unicode格式的字集允許將大字體分割成較小的集合。這是一個(gè)相對(duì)先進(jìn)的方案，特別是針對(duì)亞洲語言的時(shí)候，可能會(huì)帶來顯著的空間節(jié)?。阒乐形淖煮w的平均數(shù)為20,000字形嗎？）。第一步是將字體限制為必要的語言集，例如拉丁語，希臘語或西里爾語。如果使用一個(gè)網(wǎng)絡(luò)字體只是為了進(jìn)行標(biāo)識(shí)，則推薦使用Unicode格式的描述符來指定字符。

The Filament Group released an Open Source command-line utility, glyph hanger that can generate a list of necessary glyphs based on files or URLs. Alternatively, the web-based Font Squirrel Web Font Generator offers advanced subsetting and optimisation options. If using Google Fonts or Typekit choosing a language subset is built into the typeface picker interface, making basic subsetting easier.
Filament團(tuán)隊(duì)發(fā)布了一個(gè)開源命令行工具，可以根據(jù)文件或URL生成必需字形列表?；蛘撸赪eb的Font Squirrel和Font Generator提供的高級(jí)字集和優(yōu)化選項(xiàng)。如果在字體選擇器界面中內(nèi)置了Google Fonts或Typekit，則使用基本字集更容易。

Establish a font loading strategy
Fonts are render-blocking?—?because the browser has to build both the DOM and CSSOM first; web fonts won’t be downloaded before they’re used in a CSS selector that matches an existing node. This behaviour significantly delays text rendering, often causing the Flash of Invisible Text (FOIT) mentioned before. FOIT is even more pronounced on slower networks and mobile devices.
由于瀏覽器必須首先構(gòu)建DOM和CSSOM，之后再渲染字體;在解析到應(yīng)用了web fonts的CSS選擇器之前，不會(huì)下載web fonts。這種行為有明顯的延遲文本現(xiàn)象，特別是前面提到的Flash隱藏文本（FOIT）。在較慢的網(wǎng)絡(luò)和移動(dòng)設(shè)備上，F(xiàn)OIT延遲更加明顯。

Implementing a font loading strategy prevents users from not being able to access your content. Often, opting for Flash of Unstyled Text (FOUT) is the easiest and most effective solution.
實(shí)施字體加載策略可防止用戶無法訪問您的內(nèi)容。通常，選擇Flash的Unstyled Text（FOUT）是最簡(jiǎn)單和最有效的解決方案。

font-display is a new CSS property providing a non-JavaScript reliant solution. Unfortunately, it has partial support (Chrome and Opera only) and is currently under development in Firefox and WebKit. Still, it can and should be used in combination with other font loading mechanisms.
font-display是提供非JavaScript依賴解決方案的新CSS屬性。不幸，它僅有部分瀏覽器支持（Chrome和Opera），目前正在Firefox和WebKit中開發(fā)。盡管如此，它應(yīng)該與其他字體加載機(jī)制結(jié)合使用。

font-display property in action

Luckily, Typekit’s Web Font Loader and Bram Stein’s Font Face Observer can help manage font loading behaviour. Additionally, Zach Leatherman, an expert on web font performance, published A Comprehensive Guide to Font Loading Strategies which will aid in choosing the right approach for your project.
幸運(yùn)的是，Typekit的Web Font Loader和Bram Stein的Font Face Observer可以幫助管理字體加載行為。此外，網(wǎng)頁字體性能專家Zach Leatherman發(fā)布了“字體加載策略綜合指南”，這將有助于為你的項(xiàng)目對(duì)web fonts的選擇。

Web font performance checklist

Chose the right format

Audit the font selection

Use Unicode-range subsetting

Establish a font loading strategy

選擇正確的格式

斟酌字體選擇

使用Unicode格式的字集

建立一個(gè)字體加載策略

使用font-display屬性

Optimising JavaScript
At the moment, the average size of JavaScript bundle is 446 KB, which already makes it second biggest type of an asset size-wise (following images).
目前，JavaScript軟件包的平均大小為446 KB，占用資源的比例已經(jīng)達(dá)到第二（僅次于圖片）。

What we might not realise is that there’s a much more sinister performance bottleneck hidden behind our beloved JavaScript.
我們可能沒有意識(shí)到，我們所愛的JavaScript隱藏著更加險(xiǎn)惡的性能瓶頸。

Monitor how much JavaScript is delivered
Optimising delivery is only one step in combating web page bloat. After JavaScript is downloaded, it has to be parsed, compiled and run by the browser. A quick look at a few popular sites and it becomes obvious that gzipped JS becomes at least three times bigger after unpacking. Effectively, we are sending giant blobs of code down the wire.
優(yōu)化傳輸只是減輕網(wǎng)頁膨脹的一步。JavaScript下載后，必須由瀏覽器進(jìn)行解析，編譯和運(yùn)行。當(dāng)你快速瀏覽一些流行的網(wǎng)站，明顯gzip壓縮的JS在解壓之后至少要增加三倍。實(shí)際上，我們正在發(fā)送一大堆代碼。

Parse times for 1MB of JavaScript on different devices. Image courtesy of Addy Osmani and his JavaScript Start-up Performance article.
在不同的設(shè)備上多次解析1MB的JavaScript。圖片由Addy Osmani和他的JavaScript Start-up Performance文章提供。

Analysing parse and compile times becomes crucial to understanding when apps are ready to be interacted with. These timings vary significantly based the hardware capabilities of users’ device. Parse and compile can easily be 2–5x times higher on lower end mobiles. Addy’s research confirms that on an average phone an app will take 16 seconds to reach an interactive state, compared to 8 seconds on a desktop. It’s crucial to analyse these metrics, and fortunately, we can do so through Chrome DevTools.
apps在解析和編譯后是否可用，分析其中的耗時(shí)至關(guān)重要。所耗時(shí)間因用戶設(shè)備的硬件功能而異。在低端手機(jī)解析和編譯比高端手機(jī)上慢2-5倍。Addy的研究證實(shí)，在一般手機(jī)上，一個(gè)應(yīng)用程序?qū)⑿枰?6秒才能正常使用，而在桌面上為8秒。分析這些指標(biāo)至關(guān)重要，幸運(yùn)的是，我們可以通過Chrome DevTools來實(shí)現(xiàn)。

Investigating parse and compile in Chrome Dev Tools
在Chrome開發(fā)工具中調(diào)查解析和編譯

Make sure to read Addy Osmani’s detailed write-up on JavaScript Start-up Performance.
請(qǐng)務(wù)必閱讀Addy Osmani對(duì)JavaScript性能優(yōu)化的詳細(xì)說明。

Get rid of unnecessary dependencies
The way modern package managers work can easily obscure the number and the size of dependencies. webpack-bundle-analyzer and Bundle Buddy are great, visual tools helping identify code duplication, biggest performance offenders and outdated, unnecessary dependencies.
現(xiàn)代軟件包管理器的工作方式可以輕而易舉地掩蓋依賴包的數(shù)量和大小。webpack-bundle-analyzer和Bundle Buddy是很好的可視化工具，幫助識(shí)別重復(fù)代碼，最大的性能阻礙和過時(shí)的、不必要的依賴。

Webpack bundle analyzer in action.
使用中的Webpack bundle analyzer

We can make imported package cost even more visible with Import Cost extension in VS Code and Atom.
通過導(dǎo)入VS Code和Atom中的擴(kuò)展，我們可以使包引入成本更加明顯。

Import Code VS Code extension.
導(dǎo)入代碼VS導(dǎo)入代碼擴(kuò)展。

Implement code splitting
Whenever possible, we should only serve the necessary assets to create the desired user experience. Sending a full bundle.js file to the user, including code handling interactions they might never see is less than optimal (imagine downloading JavaScript handling an entire app when visiting a landing page). Similarly, we shouldn’t be universally serving code targeting specific browsers or user agents.
只要有可能，我們只需提供必要的資源來實(shí)現(xiàn)所需的用戶體驗(yàn)。向用戶發(fā)送一個(gè)完整的bundle.js文件，包括他們可能永遠(yuǎn)看不到的代碼，處理交互效果是不太理想的（假設(shè)在訪問首頁時(shí)下載JavaScript處理整個(gè)應(yīng)用程序）。同樣，我們不應(yīng)該普遍投放針對(duì)特定瀏覽器或用戶代理的代碼。

Webpack, one of the most popular module bundlers, comes with code splitting support. Most straightforward code splitting can be implemented per page (home.js for a landing page, contact.js for a contact page, etc.), but Webpack offers few advanced strategies like dynamic imports or lazy loading that might be worth looking into as well.
Webpack是最受歡迎的模塊打包工具之一，支持代碼拆分。最明顯的是可以每頁實(shí)現(xiàn)代碼拆分（用于首頁的home.js，聯(lián)系人頁面的contact.js等），并且Webpack提供了幾個(gè)的高級(jí)策略，例如動(dòng)態(tài)導(dǎo)入和延遲加載，值得一看。

Consider framework alternatives
JavaScript front-end frameworks are constantly on the rise. According to the State of JavaScript 2016 survey React is the most popular option. Carefully auditing architecture choices though might show that you’d be better off with a much more lightweight alternative such as Preact (note that Preact isn’t trying to be a full React reimplementation, just a highly performant, less featured virtual DOM library). Similarly, we can swap bigger libraries for smaller altrnatives?—?moment.js for date-fns (or in particular case of moment.js remove unused locales).
JavaScript前端框架不斷增加。根據(jù)2016年對(duì)JavaScript的調(diào)查，React是最受歡迎的選擇。仔細(xì)考慮架構(gòu)選擇，雖然你可能會(huì)使用更為輕量級(jí)的替代方案（例如Preact）（請(qǐng)注意，Preact不會(huì)是一個(gè)完整的React重新實(shí)現(xiàn)，只是一個(gè)高性能，功能較差的虛擬DOM庫）。類似地，我們可以用較小的庫來替代 - 例如用于date-fns的moment.js（或者是刪除moment.js未使用的部分）。

Before starting a new project, it’s worthwhile to determine what kind of features are necessary and pick the most performant framework for your needs and goals. Sometimes that might mean opting for writing more vanilla JavaScript instead.
在開始一個(gè)新項(xiàng)目之前，確定什么樣的功能是必要的，并為你的需求和目標(biāo)選擇最具性能的框架。不過可能意味著選擇寫更多的JavaScript代碼。

JavaScript performance checklist

Monitor how much JavaScript is delivered

Get rid of unnecessary dependencies

Implement code splitting

Consider framework alternatives

監(jiān)控JavaScript的傳輸

避免不必要的依賴

代碼拆分

框架選擇的考慮

Tracking performance and the road forward
We’ve talked about several strategies that in most cases will yield positive changes to the user experience of products we’re building. Performance can be a tricky beast though, and it’s necessary to track the long-term results of our tweaks.
我們已經(jīng)討論過幾種策略，在大多數(shù)情況下會(huì)對(duì)我們正在建立的產(chǎn)品的用戶體驗(yàn)產(chǎn)生積極的變化。性能可能是一個(gè)棘手的問題，而且有必要跟蹤我們調(diào)整的長(zhǎng)期結(jié)果。

User-centric performance metrics
Great performance metrics aim to be as close to portraying user experience as possible. Long established onLoad, onContentLoaded or SpeedIndex tell us very little about how soon sites can be interacted with. When focusing only on the delivery of assets, it’s not easy to quantify perceived performance. Fortunately, there are a few timings that paint quite a comprehensive picture of how soon content is both visible and interactive.
優(yōu)秀的性能指標(biāo)旨在盡可能接近用戶體驗(yàn)。長(zhǎng)期建立onLoad，onContentLoaded或SpeedIndex告訴我們很少關(guān)于網(wǎng)站可以互動(dòng)多久的信息。當(dāng)僅關(guān)注資源傳輸時(shí)，是不容易確定性能的。幸運(yùn)的是，有一些時(shí)間點(diǎn)的圖片可以全面地描述內(nèi)容的顯示和交互過程。

Those metrics are First Paint, First Meaningful Paint, Visually Complete and Time to Interactive.
這些指標(biāo)是第一次繪制，第一次有意義的繪制，視覺完整和互動(dòng)時(shí)間。

First Paint: the browser changed from a white screen to the first visual change.

First Meaningful Paint: text, images and major items are viewable.

Visually Complete: all content in the viewport is visible.

Time to Interactive: all content in the viewport is visible and ready to interact with (no major main thread JavaScript activity).

第一次繪制：瀏覽器從白色屏幕到第一次視覺變化。

第一次有意義的繪制：文字，圖像和主要模塊可見。

視覺完整：視窗中的所有內(nèi)容都可見。

互動(dòng)時(shí)間：視窗中的所有內(nèi)容都是可見的，可以隨時(shí)進(jìn)行交互（沒有主要的JavaScript線程活動(dòng)）。

These timings directly correspond to what the users see therefore make excellent candidates for tracking. If possible, record all, otherwise pick one or two to have a better understanding of perceived performance. It’s worth keeping an eye on other metrics as well, especially the number of bytes (optimised and unpacked) we’re sending.
這些時(shí)間點(diǎn)直接對(duì)應(yīng)于用戶看到的優(yōu)秀性能跟蹤。如果可能，記錄全部，否則選擇一兩個(gè)來更好地了解感知的表現(xiàn)。值得注意的是其他指標(biāo)，特別是我們發(fā)送的字節(jié)數(shù)（優(yōu)化和解壓）。

Setting performance budgets
All of these figures might quickly become confusing and cumbersome to understand. Without actionable goals and targets, it’s easy to lose track of what we’re trying to achieve. A good few years ago Tim Kadlec wrote about the concept of performance budgets.
所有這些數(shù)字可能會(huì)很快會(huì)使理解變得混亂和麻煩。沒有可操作的目標(biāo)和場(chǎng)景，很容易偏離我們正在實(shí)現(xiàn)的內(nèi)容。幾年前，Tim Kadlec寫了關(guān)于性能預(yù)算的概念。

Unfortunately, there’s no magical formula for setting them. Often performance budgets boil down to competitive analysis and product goals, which are unique to each business.
不幸的是，沒有設(shè)置它們的神奇公式。性能預(yù)算通常歸結(jié)為競(jìng)爭(zhēng)分析和產(chǎn)品目標(biāo)，這是每個(gè)業(yè)務(wù)都不同的。

When setting budgets, it’s important to aim for a noticeable difference, which usually equals to at least 20% improvement. Experiment and iterate on your budgets, leveraging Lara Hogan’s Approach New Designs with a Performance Budget as a reference.
設(shè)定預(yù)算時(shí)，重要的是要達(dá)到明顯的效果，通常至少改善20％。實(shí)踐和迭代您的預(yù)算，利用Lara Hogan新設(shè)計(jì)的方法，作為性能預(yù)算參考。

Try out Performance Budget Calculator or Browser Calories Chrome extension to aid in creating budgets.
試用性能預(yù)算計(jì)算器或?yàn)g覽器卡路里Chrome擴(kuò)展程序來幫助建立預(yù)算。

Continuous monitoring
Monitoring performance shouldn’t be manual. There are quite a few powerful tools offering comprehensive reporting.
監(jiān)控性能不應(yīng)該是手動(dòng)的。有很多強(qiáng)大的工具提供全面的反饋。

Google Lighthouse is an Open Source project auditing performance, accessibility, progressive web apps, and more. It’s possible to use Lighthouse in the command line or as just recently, directly in Chrome Developer Tools.
Google Lighthouse是一個(gè)審核性能，可訪問性，漸進(jìn)式網(wǎng)絡(luò)應(yīng)用程序等的開源項(xiàng)目?？梢栽诿钚兄谢蛑苯釉贑hrome Developer Tools中使用Lighthouse。

Lighthouse performing a performance audit.
Lighthouse執(zhí)行性能審計(jì)。

For continuous tracking opt-in for Calibre that offers performance budgets, device emulation, distributed monitoring and many other features that are impossible to get without carefully building your own performance suite.
根據(jù)Calibre的連續(xù)跟蹤選項(xiàng)，可以提供性能預(yù)算，設(shè)備仿真，分布式監(jiān)控和許多其他功能，無需仔細(xì)構(gòu)建自己的性能套件即可獲得。

Comprehensive performance tracking in Calibre.
全面的性能跟蹤。

Wherever you’re tracking, make sure to make the data transparent and accessible to the entire team, or in smaller organisations, the whole business.
無論您在跟蹤什么地方，請(qǐng)確保使整個(gè)團(tuán)隊(duì)或整個(gè)企業(yè)的小型組織能夠透明地訪問數(shù)據(jù)。

Performance is a shared responsibility, which spans further than developer teams?—?we’re all accountable for the user experience we’re creating, no matter role or title.
性能是一項(xiàng)共同責(zé)任，甚至高于開發(fā)團(tuán)隊(duì)，我們對(duì)所創(chuàng)建的用戶體驗(yàn)負(fù)責(zé)，無論處于什么樣的職位和角色。

It’s incredibly important to advocate for speed and establish collaboration processes to catch possible bottlenecks as early as product decisions or design phases.
倡導(dǎo)速度和建立協(xié)作流程，在處理產(chǎn)品決策或設(shè)計(jì)階段早期可能遇到的瓶頸是非常重要的。

Building performance awareness and empathy
Caring about performance isn’t only a business goal (but if you need to sell it through sales statistics do so with PWA Stats). It’s about fundamental empathy and putting the best interest of the users first.
關(guān)心性能不僅僅是一個(gè)業(yè)務(wù)目標(biāo)（但是如果您需要通過銷售統(tǒng)計(jì)數(shù)據(jù)來進(jìn)行銷售，那么用PWA統(tǒng)計(jì)）。基本的共識(shí)和使用者的最大利益是第一位。

As technologists, it’s our responsibility not to hijack attention and time people could be happily spending elsewhere. Our objective is to build tools that are conscious of time and human focus.
作為技術(shù)專家，不要過分控制注意力和時(shí)間，人們可能會(huì)樂意花費(fèi)時(shí)間在其他地方。我們的目標(biāo)是建立可以節(jié)省時(shí)間和人性化的工具。

Advocating for performance awareness should be everyone’s goal. Let’s build a better, more mindful future for all of us with performance and empathy in mind.
倡導(dǎo)性能意識(shí)應(yīng)該是每個(gè)人的目標(biāo)。讓我們通過性能共識(shí)建立一個(gè)更好，更有意義的未來。