Front-End Performance Checklist 2021[1]


https://www.smashingmagazine….


Front-end performance optimization (I) : preparation work [2]


Front-end performance optimization (II) : resource optimization [3]


Front-end performance optimization (III) : construction optimization [4]


Front-end performance optimization (IV) : transmission optimization [5]


Front-end Performance Optimization (V) : Network and HTTP/2[6]

I. Optimize the audit workflow

This may not sound like a big deal, but getting it right easily can save you a lot of testing time. Consider using Tim Kadlec’s Alfred workflow to submit a test to a public instance of WebPageTest. In fact, WebPageTest has a lot of obscure features, so take some time to learn how to read the WebPageTest waterfall view diagram [7] and how to read the WebPageTest connect view diagram [8] to diagnose and resolve performance problems faster.

You can also drive WebPageTest from Google Spreadsheets and import accessibility, performance, and SEO scores and Lighthouse CI into your Travis Settings, or directly into Webpack.

Take a look at the recently released Autowebperf, a modular tool that automatically collects performance data from multiple sources. For example, we can set up daily tests on your key pages to capture field data from the Crux API and lab data from PageSpeed Insights’ Lighthouse report.

If you need to debug something quickly, but your build process seems to be slow, keep in mind that “with most JavaScript, no detailed code conversion is required, whitespace removal and symbol modification accounts for 95% of the reduction in the size of the reduced code. You can speed up Uglify builds by three to four times simply by disabling compression.”

(a) WebPageTest

Go to www.webpagetest.org and type in your website to get the results.

1. Waterfall View Chart [7]

How to Read a Webpagetest Waterfall View Chart by Matt Hobbs [7]

(1) Basic layout

S the Key

Display three types of information:

● Information about the status of the connection (DNS lookup, connection establishment, SSL negotiation) ● Type of resource requested (such as HTML, images, etc.) ● Miscellaneous events (WAIT, JavaScript execution)

Each resource comes in two colors, light and dark. The light colors indicate the point in time when the browser made the request for the resource, and the dark colors indicate the point at which the resource was actually downloaded.

“Wait” visualization is a new feature in WPT. It shows the time between when the browser first discovered the resource on the page and when the browser made a resource request to the server.

S Request list

The list of assets the browser finds on the page and the order in which they are requested, notice the request number on the far left and the yellow lock if the request is made over a secure connection (HTTPS).

S Request timeline

Timelines show the time along the horizontal (x) axis versus the vertical (y) axis on each request. From there you can see the lifecycle of the request made by the browser: from discovery (wait), to making the request, and finally to downloading the asset.

Make sure this timeline covers as little time as possible, as this indicates better overall performance. The thinner the timeline, the faster the user will load the page.

S CPU Utilisation

A simple chart showing the CPU utilization of browser processes running on the device. It shows the number of CPUs being used by the current page at any point in time. It ranges from 0 to 100% utilization.

S Bandwidth In

This is an indicator of when the data enters the browser. Visualization helps to see if the browser is doing useful work or wasting time. The absolute ratio can be ignored because it’s not very accurate. If you want more accurate results, use the “Capture Network Packet Dump” option on the advanced TAB of the WebPageTest home page.

S Browser the main thread

This figure visualizes what the browser main thread is doing at any given point in time (the X-axis). The y axis shows the percentage of 0-100%. The colors are copied from the Chrome DevTools CPU chart (under the Performance TAB). Here’s what each color means:

● Orange - Script Parsing, Evaluation and Execution ● Purple - Layout ● Green - Painting ● Blue - HTML Parsing ● Gray - Main thread time for task processing is not counted in other categories

Use this diagram to see if the CPU is becoming a bottleneck in one of the above areas.

■ Page is interactive(Long Tasks)

This diagram indicates when the main thread is blocked. The red block indicates that the main thread has been blocked for 50 milliseconds (this also blocks inputs like button presses). Green indicates that the thread is not blocked. Note: Scrolling is still possible during the red blocking phase, because for most browsers, scrolling is usually handled outside the main thread.

Note: As of February 2021, “Page is Interactive “has been renamed to “Long Tasks”. Everything stays the same except the name.

(2) Vertical lines

■ Start render-green line

This is the first point where the user will see the pixels drawn onto the page. Pixels can come from anything (background color, borders, etc.), not necessarily content. Before that, the screen is blank. This metric is measured by analyzing a single video frame captured during the page load.

■ First Contentful Paint – Light green line

This is the point at which the browser renders anything on the screen that is visually different than before navigation (that is, WPT’s blank screen). If the test browser supports the PerformanceObserver API, this metric is reported using the browser’s performance timeline. Therefore, this value is the time it thinks the first content will be drawn to the viewport.

■ Largest Contentful Paint – Dark green err line

Largest Contentful Paint is an important metric, and it’s part of Core Web Vitals. This is a user-centric metric that helps developers understand the perceived performance of a Web page. In fact, it reports the render time relative to the maximum image or block of text visible in the viewport when the page starts loading.

■ Layout shift-orange err line

The Page Cumulative Layout Offset (CLS) score is another metric for Core Web Vitals. User-centric metrics that measure the overall stability of a page. WebPageTest will highlight each unexpected layout offset detected by the test browser API. Unexpected layout transitions are not caused by user input (such as pressing a button).

Note: You can have multiple layout transitions on the waterfall diagram because you can have multiple layout transitions during the test. The layout shift line is the only row in the key where this happens.

■ Dom interactive-yellow line

The moment when the browser finishes parsing all the HTML and the DOM construction is complete. Unfortunately, this is not a reliable indicator.

■ DOM Content Loaded – Pink line

The HTML is loaded and parsed and the browser reaches the point at the end of the document. All blocking scripts have been loaded and run, and the DOM is now fully defined. Notice the thickness of this line in the key. This is to show that the line covers a period of time, rather than a single point in time in the waterfall.

■ On load-lavender line

The point at which the window load event is triggered. All the objects are in the DOM, and all the images and scripts have been loaded. Notice the thickness of this line. This is to show that the line covers a period of time, rather than a single point in time in the waterfall.

■ Document complete-blue line

The point that fires the onload event and all static image content has been loaded. Content changes triggered by JavaScript execution may not be included.

(3) Horizontal timings

The request timeline. If you click on a single request, you’ll see a pop-up with more information, as shown in the following example:

(4) The HTML

The detailed time of request is as follows:

● Request Start: 0.116 seconds ● DNS Lookup: 27 milliseconds ● Initial Connection appears: 0.011 seconds ● Request Start: 0.116 seconds ● DNS Lookup: 27 milliseconds ● Initial Connection appears: 0.011 seconds ● Request Start: 0.116 seconds ● Negotiation: 25ms ● Time to First Byte ● Download: 40 ms ● Negotiation: 25ms ● Time to First Byte ● Negotiation: 25ms ● Time to First Byte

(5) A third-party JavaScript file

This request is different from the other requests examined because the file comes from a different domain. The detailed time of request is as follows:

● Request Start: 0.702 seconds ● DNS Lookup: 28 milliseconds ● Initial Connection appears: ● Request Start: 0.702 seconds ● Negotiation: 153ms ● Time to First Byte: 48ms ● Download: 9ms ● Negotiation: 153ms ● Time to First Byte

Note that the browser needs to do the entire connection negotiation (DNS, connection, SSL negotiation) again, because the file exists in a different domain. This adds a considerable amount of time to the request (28 + 39 + 153 = 220 milliseconds).

(6) A sponsor PNG

With this request, the browser finds a PNG image and requests it from the server. The detailed time of request is as follows:

● Discovered: 0.652 seconds ● Time to First Byte: 214 milliseconds ● Download: Discovered: 0.652 seconds ● Request Start: 0.824 seconds ● Time to First Byte: 214 milliseconds ● Download: Discovered: 0.652 seconds ● Request Start: 0.824 seconds ● Time to First Byte: 214 milliseconds ● Download: Discovered: 0.652 seconds ● Request Start: 0.824 seconds ● Time to First Byte: 214 milliseconds ● Download: 28 milliseconds

The wait time is calculated by subtracting the discovery time from the request start time. The wait time is the time the browser first finds the asset until it is able to send a request to the server.

The duration after this request is the time between the request being made and the request being completed (first byte time + content download). Since the connection to the domain is already established, no DNS, connection, SSL negotiation is required.

(7) GIF File Moved

The background of the request is yellow, indicating that the server response status code is not the usual 200. In this case, it is the 302 status code, which indicates that the GIF file has been temporarily moved. In fact, all responses with a 3xx status code will have a yellow background. The request details are as follows:

The request does not require a TCP connection to be established because it has already occurred for the domain in request 20.

The error status codes 4xx and 5xx are displayed in a similar manner, except for the red background, as shown in the following example (this image is from a different test) :

Notice the color of the resource response returned in this example, which is not the expected purple color of the image, but the blue color of the HTML page. Or, in other words, the server responds to a 404 page because the asset is not found.

(8) Download chunks

Lighter colors indicate that a request has been made and the browser is waiting for a response, and darker colors indicate that bytes for a particular resource are being delivered to the browser. Sometimes this doesn’t happen at the same time. This causes it to look like zebra stripes and over time the browser is trickling bytes. These are called download blocks (red arrows).

This is because a large number of assets are downloaded in parallel and compete for resources.

(9) Inline script execution

If you have a lot of inline scripts in your page (Google Analytics, Dreamweaver MM_Preloadimages, etc.). How will they be visualized?

Here we see the browser downloading HTML blocks, and then very close to those downloads we see the JavaScript execution lines (pink). This is inline JavaScript from the page being executed. If you look closely in the browser’s main thread, you’ll see the HTML parsing (blue) and a very small yellow slider to indicate JavaScript execution.

(10) Updated JavaScript execution visualisation

WebPageTest recently updated the JavaScript execution view on the waterfall diagram to distinguish between very intensive JavaScript execution and short but rapid repeated execution:

Now, when JavaScript execution is rendered, you don’t always see a pink solid block. The height of the pink bar indicates how fast the JavaScript is running. Fast but frequent JavaScript executions will have very short height bars that no longer dominate the view.

(11) Different First Byte values

At the far left of the table, there is a column of “First Byte”, and when you click the HTML request on the page, you will also see “Time to First Byte”. These two values are different, the “First Byte” in the top table is the sum of all these values (Discovered + DNS + Connect + SSL + TTFB), It’s basically the time it takes from NavigationStart to the browser to receive the first byte of data from the server. The “Time to First Byte” is just the Time from the start of the request until the First data Byte is received.

Common scenarios:

S DNS – prefetch

DNS PREFETCH tells the browser that another domain will need a DNS lookup in the near future. So instead of waiting, start looking right away. When the domain is actually needed, the browser only needs to complete the TCP handshake and the optional SSL negotiation.

S Preconnect

Preconnect allows developers to give the browser a “hint” that they will also need to connect domains in the near future. By connecting to the domain as early as possible, the connection will not need to be established later in the waterfall, allowing assets from the domain to be requested and downloaded more quickly when needed.

S Prefetch

PREFETCH allows the developer to tell the browser to Prefetch resources (such as CSS, JS, HTML documents) in the current navigation as it may be needed later. For example, if you know that most users navigate from your home page to a particular page (perhaps your login page, for example), you can decide to prefetch it so that it already exists in the user’s browser cache when needed.

WebPageTest gives us some information in the pop-up window to let us know that this is a prefetch prompt:

● Purpose: Prefetch (under the Request TAB)

In WebPageTest, it is listed as Priority: Idle when tested in Chrome. This maps to the lowest priority in DevTools (based on resource priorities and scheduling in the Chromium documentation). So prefetch is an optional and usually low-priority fetch, and the browser loads it as late as possible. This is different from preload, which is mandatory and gets high priority in the browser. Resources loaded with preload can block the layout, so use it with caution, or it may actually reduce perceived performance.

S Preloading

Preload is used to increase the load priority of the selected resource. The developer can tell the browser, “This resource will be needed soon, so load it now.” This technique is often used when loading web fonts.

Without Preload, when loading a Web font, the browser first needs to download the HTML and CSS and then parse them to create a rendering tree. Only then can the browser request the font. This can lead to so-called invisible text blinking (FOIT) and styleless text blinking (FOUT). One way to solve this problem is to use the preload directive to request the Web font file immediately.

Using preload:

Do not use preload:

HTTP / 2 s HTTP / 1.1 v

HTTP / 1.1

HTTP/2

S OSCP

Online Certificate Status Protocol (OCSP) is an Internet protocol used to obtain the revocation status of SSL certificates. One way for a browser to verify a certificate is to connect to an OCSP server for verification. When this happens, WebPageTest will show up in the waterfall as follows:

This OCSP check is bad for performance. Validation requires a DNS lookup and an initial connection to the OCSP server. SSL negotiation with the original domain can only take place after the certificate has been validated. As you can see in the image, the whole waterfall is pushed back. It takes almost two seconds to request an HTML page!

If you notice this on the WebPageTest timeline, you should consider enabling OCSP Stapling on your server. Note: If you are using Extended Validation Certificates (EVs), OCSP Stapling does not fully solve the problem.

S Service worker precaching

An important detail to keep in mind when using Service workers to pre-cache assets is that the browser may need to download the same file twice. Once for the HTTP Cache (standard browser Cache) and again for the Service Worker Cache (Cache API). These are two completely separate caches that do not share assets.

In requests 17 and 18, you can see that the service worker JavaScript is requested, downloaded, and initialized. Next, the Service Worker looks at its pre-cached JSON file and requests any assets listed. Note: In the above example, the Workbox library is used to simplify the Service Worker workflow.

In addition, WebPageTest has added a new feature where requests that are not from the home page document (such as <iframe> and Service Worker requests) are now highlighted in blue (Chrome only).

■ Large Time to First Byte (TTFB)

Time to First Byte is the Time between the browser requesting the First resource and the server sending the First Byte of data back to the browser. It includes:

● The time it takes for the packet to be transmitted from the browser to the server ● The time it takes for the server to receive the request, process and build the response, and transmit it back ● The time it takes for the response packet to be transmitted from the server to the browser

The time required to travel from the browser to the server is called network latency. Data sent back and forth is called round-trip (RTT). So when you have a big TTFB, how do you use WebPageTest to identify it?

The above test was run on a standard “Cable” connection defined by WebPageTest, so the RTT for that connection was 28 milliseconds. Now, if we compare this value to TTFB, which is 3.1 seconds, we can see that there is a problem here. By looking at the connection negotiation time (orange in request 3), you can get an idea of how fast the packet is moving across the network (32 milliseconds in this case). Therefore, it is clear that the TTFB delay is not caused by network congestion. According to the bandwidth graph, there is zero activity on the network and quite little activity on the CPU. The device is waiting for the server to respond before it can do anything else.

In this case, it is the processing time on the server that is causing the delay. Whatever the server does to build the response takes about three seconds. That’s a lot of time to build HTML. There are many reasons to list as to why this might happen on the server, but a good starting point is to look at database queries, hosting Settings, available server resources, and running server software. Any cause of the problem needs to be identified and fixed, as this can have a huge impact on site users. So if you see a WebPageTest waterfall like this, check your server Settings and try to reduce this time. As mentioned by Harry Roberts in his article “Time to First Byte: What It Is and Why It Matters” :

While a good TTFB does not necessarily mean you will have a fast site, a bad TTFB will almost certainly guarantee a slow site.

2. Connection view diagram [8]

The number of lines in the connection view means how many TCP connections are created when the site is loaded, and each of these connections involves some form of DNS, TCP, SSL negotiation, which is expensive in time and affects Web performance. The Connections view is a good way to quickly see how many connections there are and how each connection is being used. Using it in conjunction with the waterfall view will allow you to quickly identify potential performance issues that would be difficult to find using the waterfall view alone.

To learn more about the connection view, read the connection view article [8].

(2) Autowebperf (AWP) [9]

AWP is a module-based library that contains three different types of modules:

● Engine ● Connector module ● Acquisition module

For example, you can use the following command to run an audit on a list of tests stored in a Google table and write the results to a CSV file:

PSI_APIKEY=<YOUR_KEY> SHEETS_APIKEY=<YOUR_KEY> ./awp run sheets:<SheetID> csv:output.csv

After collecting daily metrics in your spreadsheet, you can create a Data Studio dashboard that loads Data directly from the spreadsheet and plots trends as time series graphs. Check out the Google Spreadsheet API Connector [10] for detailed steps on how to set up AWP for visualization on Data Studio using a spreadsheet as a Data source.

Second, test in proxy browsers and traditional browsers

Testing in Chrome and Firefox is not enough. See how your site works in proxy browsers and older browsers. For example, UC Browser and Opera Mini are available in AsiaSignificant market share [11](Up to 35% in Asia).Measure the average Internet speed in the country/region you are interested in [12]To avoid major surprises in the future. Test with network throttling and simulate high DPI devices. BrowserStack is great for testing on remote, real devices, and complementing it with at least some real devices in your office — it’s worth it.

The average Internet speed in China is as follows:

Third, test the performance of 404 pages

Usually we don’t think twice about 404 pages. After all, when a client requests a page that doesn’t exist on the server, the server responds with a 404 status code and the associated 404 page. There’s not that much to think about, is there?

An important aspect of a 404 response is the actual response body size sent to the browser. According to Matt Hobbs’ research on 404 pages [13], the vast majority of 404 responses come from missing ICONS, WordPress upload requests, corrupted JavaScript requests, manifest files, and CSS and font files. Every time a user requests an asset that doesn’t exist, they get a 404 response — and that response is usually huge.

Be sure to check and optimize caching policies for 404 pages. The goal is to provide HTML to the browser only when the browser needs the HTML response, and return a small error load for all other responses. According to Matt, “If we put a CDN in front of the server, we have the opportunity to cache 404 page responses on the CDN. This is useful because without it, clicking on a 404 page could be used as a DoS attack vector by forcing the source server to respond to every 404 request, rather than having the CDN response cached version.”

404 errors not only affect your performance, but also cause traffic loss, so it’s a good idea to include a 404 error page in your Lighthouse test suite and track its score over time.

Test the performance of GDPR consent prompt

In the era of GDPR and CCPA, it has become common to rely on third parties to offer EU users the option to opt in or out of tracking. However, as with any other third-party script, their performance can have a fairly disruptive impact on the overall performance effort.

Of course, the actual consent may change the impact of the script on overall performance, so, as Boris Schapira points out, we might want to explore a few different Web performance profiles:

● Agree Fully Rejected ● Agree Partly Rejected ● Full Consent ● The user does not take action on the consent prompt (or the prompt is blocked by a content blocker)

Usually Cookie Consent hints should not have an impact on CLS, but sometimes they do, so consider using the free and open source options OSAO or Cookie-Consent Box.

In general, it is worth investigating pop-up performance, as you need to determine the horizontal or vertical offset of mouse events and position the pop-up correctly relative to the anchor point. Noam Rosenthal shares the Wikimedia team’s experience in the article Web Performance Case Study: Wikipedia Page Previews [14], which also provides videos [14-A] and meeting notes [14-B].

Five, performance diagnosis CSS

While we can include various checks to ensure that underperforming code is deployed, it is often useful to quickly learn some low-hanging water that can be easily resolved. To do this, we can use Tim Kadlec’s excellent Performance Diagnostics CSS (inspired by the Harry Roberts snippets), which highlights lazy-loaded images, unresized images, old format images, and synchronization scripts.

For example, you might want to make sure that any images above the fold are not lazily loaded. You can customize code snippets as needed, such as highlighting unused web fonts, or detecting icon fonts. A great gadget to make sure you see errors during debugging, or just a quick review of the current project.

/* Performance Diagnostics CSS */
/* via Harry Roberts. https://twitter.com/csswizardry/status/1346477682544951296 */
img[loading=lazy] {
  outline: 10px solid red;
}

The impact of testing on accessibility

When the browser starts loading the page, it builds a DOM and, if there are assistive technologies such as screen readers running, an accessibility tree. The screen reader must then query the accessibility tree to retrieve the information and make it available to the user – sometimes by default, sometimes on demand, and sometimes in time.

When we talk about fast interaction time, we usually mean the amount of time that a user can interact with a page by clicking or clicking links and buttons. The context for screen readers is slightly different. In this case, the fast interaction time means how much time has elapsed before the screen reader can display navigation on a given page and the screen reader user can actually click on the keyboard to interact.

Leonie Watson gave an eye-opening presentation on accessibility performance [15], in particular the impact of slow loading on screen reader announcement latency. Screen readers, accustomed to fast-paced announcements and quick navigation, may be more impatient than sighted users.

Large pages and DOM manipulation using JavaScript will cause screen reader notification delays. This is an unexplored area that needs some attention and testing as screen readers are available on every platform (JAWS, NVDA, VoiceOver, Trader, Orca).

7. Set up continuous monitoring

Having a private instance of WebPageTest is always beneficial for fast and unlimited testing. However, continuous monitoring tools with automatic alerts, such as Sitespeed, Calibre, and SpeedCurve, can give you a more detailed view of your performance. Set up your own user timing markers to measure and monitor business-specific metrics. In addition, consider adding automatic performance regression alerts to monitor its changes over time.

Consider using a RUM solution to monitor performance over time. For automated unit test class load testing tools, you can use K6 and its scripting API. Also, check out SpeedTracker, Lighthouse, and Calibre.

Quick scheme

This list is very comprehensive, and it may take a long time to complete all the optimizations. So, what would you do if you only had 1 hour to make a significant improvement? Let’s boil it all down to 17 low-hanging fruit goals. Obviously, before starting and after finishing, the measurement results include maximum content drawing and interaction time on 3G and cable connections.

Measure real-world experiences and set appropriate goals. The goal is to be at least 20% faster than the fastest competitor. Keep maximum content drawing < 2.5 seconds, first input delay < 100 milliseconds, interaction time < 5 seconds (slow 3G), repeated access, TTI < 2 seconds. Optimize at least for initial content drawing and interaction time.

02 optimized images using Squoosh, Mozjpeg, Guetzli, Bingo and SVGOMG, and provided Avif /WebP using image CDN.

03 Prepare key CSS for the master template and inline them to <head> for each template. For CSS/JS, key file sizes are kept within budget [170KB gzipped (0.7MB decompressed)].

Pruning, optimizing, delaying, and lazy-loading scripts. Set up the packaging configuration to eliminate redundancy and examine the lightweight alternatives.

Always self-escrow your static assets, and always self-escrow third party assets. Limit the impact of third-party scripts. Using a facade, load widgets at interaction time and watch for flicker-proof fragments.

Be selective when choosing a frame. For single-page applications, identify critical pages and serve them statically, or at least pre-render them, and use progressive hydration at the component level and load modules at interaction time.

Stand-alone client rendering is not a good choice for performance. If your page doesn’t change much, use pre-render, and if you can, delay the start of the frame. If you can, consider streaming server-side rendering.

08 only uses <script type=”module”> and the module/ noModule mode to provide old code to old browsers.

09 Try to regroup the CSS rules and test the CSS inside the body.

Add resource hints to speed up page loading such as “dns-lookup”, “preconnect”, “prefetch”, “preload”, and “prerender”.

11. Set up a Web font subset and load it asynchronously, and use the font-display in CSS to achieve a fast first rendering.

Check that the HTTP cache headers and security headers are set correctly.

13 Enable Brotli compression on the server. (If this is not possible, at least make sure that Gzip compression is enabled.)

14 Enable TCP BBR congestion as long as your server is running on Linux kernel version 4.9+.

15. Consider enabling OCSP Stapling and IPv6. Always provide OCSP Stapling’s DV certificate.

16 Enable HPack compression for HTTP/2 and move to HTTP/3 (if available).

17 Cache assets such as fonts, styles, JavaScript, and images in the Service Worker cache.

Download the checklist (PDF, Apple Pages)

● Download the Checklist PDF[16] (PDF, 166KB) ● Download the Checklist in Apple Pages[17] (.pages, ● Download the Checklist in MS Word[18] (.docx, 151KB)

Welcome to follow my personal official account:

References:

Front – End Performance Checklist 2021 [1] : https://www.smashingmagazine… Front end performance optimization (a) : the preparation [2] : https://mp.weixin.qq.com/s/QD… Front end performance optimization (2) : resource optimization [3] : https://mp.weixin.qq.com/s/Yb… Front end performance optimization (3) : build optimization [4] : https://mp.weixin.qq.com/s/sp… Front end performance optimization (4) : transmission optimization [5] : https://mp.weixin.qq.com/s/Iq… Front end performance optimization (5) : network and HTTP / 2 [6] : https://mp.weixin.qq.com/s/lL… How to read a WebPageTest Waterfall View chart [7] : https://nooshu.github.io/blog… How to read a WebPageTest Connection View chart [8] : https://nooshu.github.io/blog… Google Spreadsheets AutoWebPerf [9] : https://web.dev/autowebperf/ API Connector [10] : https://github.com/GoogleChro… Browser market share [11] : https://gs.statcounter.com/br… Measuring the average speeds [12] : https://www.webworldwide.io/ according to you should be testing your 404 pages web performance [13] : https://nooshu.github.io/blog… Web performance case study: Wikipedia page previews [14] : https://techblog.wikimedia.or… Video [14 – a] : https://www.youtube.com/watch… Meeting record [14 – b] : https://docs.google.com/docum… There ‘s more to Performance than meets the Eye [15] : https://www.youtube.com/watch… Download the checklist PDF [16] : https://www.dropbox.com/s/34n… Download the checklist in Apple Pages [17] : https://www.dropbox.com/s/iku… Download the checklist in MS Word [18] : https://www.dropbox.com/scl/f…