Results for: https://yehuang.me/
Jun 5, 2017, 4:17 PM GMT+3 •
Runtime settings
Runtime environment
- User agent: Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5 Build/MRA58N) AppleWebKit/537.36(KHTML, like Gecko) Chrome/59.0.3033.0 Mobile Safari/537.36
- :
- Device Emulation Nexus 5X: Enabled
- Network Throttling 562.5ms RTT, 1.4Mbps down, 0.7Mbps up: Enabled
- CPU Throttling 4x slowdown: Enabled
100
Progressive Web App
These audits validate the aspects of a Progressive Web App, as specified by the baseline PWA Checklist.
View 11 passed items
100
Registers a Service Worker
The service worker is the technology that enables your app to use many Progressive Web App features, such as offline, add to homescreen, and push notifications. Learn more.
100
Responds with a 200 when offline
If you're building a Progressive Web App, consider using a service worker so that your app can work offline. Learn more.
100
Contains some content when JavaScript is not available
Your app should display some content when JavaScript is disabled, even if it's just a warning to the user that JavaScript is required to use the app. Learn more.
100
Uses HTTPS
All sites should be protected with HTTPS, even ones that don't handle sensitive data. HTTPS prevents intruders from tampering with or passively listening in on the communications between your app and your users, and is a prerequisite for HTTP/2 and many new web platform APIs. Learn more.
100
Redirects HTTP traffic to HTTPS
If you've already set up HTTPS, make sure that you redirect all HTTP traffic to HTTPS. Learn more.
100
Page load is fast enough on 3G
Satisfied if the Time To Interactive duration is shorter than 10 seconds, as defined by the PWA Baseline Checklist. Network throttling is required (specifically: RTT latencies >= 150 RTT are expected).
100
User can be prompted to Install the Web App
While users can manually add your site to their homescreen, the prompt (aka app install banner) will proactively prompt the user to install the app if the various requirements are met and the user has moderate engagement with your site.
100
Configured for a custom splash screen
A default splash screen will be constructed for your app, but satisfying these requirements guarantee a high-quality splash screen that transitions the user from tapping the home screen icon to your app's first paint
100
Address bar matches brand colors
The browser address bar can be themed to match your site. A `theme-color` meta tag will upgrade the address bar when a user browses the site, and the manifest theme-color will apply the same theme site-wide once it's been added to homescreen.
100
Has a <meta name="viewport"> tag with width or initial-scale
Add a viewport meta tag to optimize your app for mobile screens. Learn more.
100
Content is sized correctly for the viewport
If the width of your app's content doesn't match the width of the viewport, your app might not be optimized for mobile screens. Learn more.
Manual checks to verify
These audits are required by the baseline PWA Checklist but are not automatically checked by Lighthouse. They do not affect your score but it's important that you verify them manually.
0
Site works cross-browser
To reach the most number of users, sites should work across every major browser. Learn more.
0
Page transitions don't feel like they block on the network
Transitions should feel snappy as you tap around, even on a slow network, a key to perceived performance. Learn more.
0
Each page has a URL
Ensure individual pages are deep linkable via the URLs and that URLs are unique for the purpose of shareability on social media. Learn more.
Metrics
These metrics encapsulate your app's performance across a number of dimensions.
293 ms
586 ms
879 ms
1.2 s
1.5 s
1.8 s
2.1 s
2.3 s
2.6 s
2.9 s
First meaningful paint2562.7ms
First meaningful paint measures when the primary content of a page is visible. Learn more.
First Interactive (beta)2,930ms
The first point at which necessary scripts of the page have loaded and the CPU is idle enough to handle most user input.
Consistently Interactive (beta)2,930ms
The point at which most network resources have finished loading and the CPU is idle for a prolonged period.
88
Perceptual Speed Index: 2373 (target: < 1,250)
Speed Index shows how quickly the contents of a page are visibly populated. Learn more.
100
Estimated Input Latency: 16ms (target: < 50 ms)
The score above is an estimate of how long your app takes to respond to user input, in milliseconds. There is a 90% probability that a user encounters this amount of latency, or less. 10% of the time a user can expect additional latency. If your score is higher than Lighthouse's target score, users may perceive your app as laggy. Learn more.
Opportunities
These are opportunities to speed up your application by optimizing the following resources.
Reduce render-blocking scripts1,035 ms
1,035 ms
Script elements are blocking the first paint of your page. Consider inlining critical scripts and deferring non-critical ones. Learn more.
View Details
URL | Size (KB) | Delayed Paint By (ms) |
|---|---|---|
…js/search.min.js | 42 KB | 1035ms |
…js/stuff.js | 4 KB | 710ms |
…js/material.min.js | 11 KB | 813ms |
Reduce render-blocking stylesheets905 ms
905 ms
Link elements are blocking the first paint of your page. Consider inlining critical links and deferring non-critical ones. Learn more.
View Details
URL | Size (KB) | Delayed Paint By (ms) |
|---|---|---|
/css?family=Cutive+Mono | 0 KB | 579ms |
/css?family=Economica&text=Crab%20Canon%20!! | 0 KB | 587ms |
/icon?family=Material+Icons | 0 KB | 643ms |
…css/material.min.css | 18 KB | 905ms |
…css/syntax.css | 1 KB | 610ms |
…css/main.css | 2 KB | 649ms |
Enable text compression160 ms28 KB
160 ms
28 KB
Text-based responses should be served with compression (gzip, deflate or brotli) to minimize total network bytes. Learn more.
View Details
Uncompressed resource URL | Original | GZIP Savings |
|---|---|---|
/ng-inspector.js | 40 KB | 28 KB (71%) |
Serve images as WebP100 ms17 KB
100 ms
17 KB
WebP images take less time to download and save cellular data. Learn more about image optimization.
View Details
URL | Original | Potential Savings | |
|---|---|---|---|
 | …homepage/fun-line.png | 17 KB | 17 KB (99%) |
Diagnostics
More information about the performance of your application.
0
Critical Request Chains: 10
The Critical Request Chains below show you what resources are required for first render of this page. Improve page load by reducing the length of chains, reducing the download size of resources, or deferring the download of unnecessary resources. Learn more.
Longest chain: 2,514.7ms
over 3 requests, totalling
12.3KB
View critical network waterfall:
Initial Navigation
()
/
(yehuang.me)
/css?family=Cutive+Mono
(fonts.googleapis.com)
- 579.5ms, 12.3KB
/css?family=Economica&text=Crab%20Canon%20!!
(fonts.googleapis.com)
- 585.8ms, 12.3KB
/icon?family=Material+Icons
(fonts.googleapis.com)
- 640.3ms, 12.3KB
…css/material.min.css
(yehuang.me)
- 901.7ms, 12.3KB
…css/syntax.css
(yehuang.me)
- 607ms, 12.3KB
…css/main.css
(yehuang.me)
- 645ms, 12.3KB
…js/search.min.js
(yehuang.me)
/l/font?kit=…
(fonts.gstatic.com)
- 582.2ms, 12.3KB
…v5/N5odNRruTwjvCM8y77PhQYgp9Q8gbYrhqGlRav_IXfk.woff2
(fonts.gstatic.com)
- 834.2ms, 12.3KB
…js/stuff.js
(yehuang.me)
- 709.1ms, 12.3KB
…js/material.min.js
(yehuang.me)
- 812.1ms, 12.3KB
View 6 passed items
100
Properly size images
Serve images that are appropriately-sized to save cellular data and improve load time. Learn more.
100
Offscreen images
Images that are not above the fold should be lazily loaded after the page is interactive. Consider using the IntersectionObserver API.
100
Optimize images
Optimized images take less time to download and save cellular data. The identified images could have smaller file sizes when compressed as JPEG (q=85). Learn more about image optimization.
100
Avoids enormous network payloads: Total size was 155 KB (target: < 1,600 KB)
Network transfer size costs users real dollars and is highly correlated with long load times. Try to find ways to reduce the size of required files.
View Details
URL | Total Size | Transfer Time |
|---|---|---|
…js/search.min.js | 42 KB | 230ms |
…011-4-71/amp-viewer.js | 25 KB | 140ms |
…css/material.min.css | 18 KB | 100ms |
…homepage/fun-line.png | 18 KB | 100ms |
/ga.js | 16 KB | 90ms |
…v5/N5odNRruTwjvCM8y77PhQYgp9Q8gbYrhqGlRav_IXfk.woff2 | 12 KB | 70ms |
…js/material.min.js | 11 KB | 60ms |
…js/stuff.js | 4 KB | 20ms |
/ | 2 KB | 10ms |
…011-4-71/amp-viewer.css | 2 KB | 10ms |
100
Avoids an excessive DOM size: 187 nodes (target: < 1,500 nodes)
Browser engineers recommend pages contain fewer than ~1,500 DOM nodes. The sweet spot is a tree depth < 32 elements and fewer than 60 children/parent element. A large DOM can increase memory, cause longer style calculations, and produce costly layout reflows. Learn more.
View details
Total DOM Nodes
187
target: < 1,500 nodes
DOM Depth
8
target: < 32
Maximum Children
32
target: < 60 nodes
100
User Timing marks and measures: 0
Consider instrumenting your app with the User Timing API to create custom, real-world measurements of key user experiences. Learn more.
91
Accessibility
These checks highlight opportunities to improve the accessibility of your app.
Elements Describe Contents Well
Screen readers and other assistive technologies require annotations to understand otherwise ambiguous content.
0
The page contains a heading, skip link, or landmark region.
Adding ways to bypass repetitive content lets keyboard users navigate the page more efficiently.
View failing elements
<html lang="en" class="mdl-js">
Color Contrast Is Satisfactory
Screen readers and other assistive technologies require annotations to understand otherwise ambiguous content.
0
Background and foreground colors have a sufficient contrast ratio.
Low-contrast text is difficult or impossible for many users to read. Learn more.
View failing elements
<span class="mu-an"><span class="mu-an"><span class="mu-an">
Elements Are Well Structured
Screen readers and other assistive technologies require annotations to understand otherwise ambiguous content.
0
Lists contain only <li> elements and script supporting elements (<script> and <template>).
Screen readers have a specific way of announcing lists. Ensuring proper list structure aides screen reader output.
View failing elements
<ul class="list">
View 7 passed items
Elements Use Attributes Correctly
Screen readers and other assistive technologies require annotations to understand otherwise ambiguous content.
100
[accesskey] values are unique.
`accesskey` attributes allow the user to quickly activate or focus part of the page.Using the same `accesskey` more than once could lead to a confusing experience.
100
<audio> elements contain a <track> element with [kind="captions"].
Captions convey information such as identifying who is speaking, dialogue, and non-speech information. This can help deaf or hearing impaired users access meaningful content.
100
Image elements have [alt] attributes.
Informative elements should aim for short, descriptive alternate text. Decorative elements can be ignored with an empty alt attribute.Learn more.
100
<input type="image"> elements have [alt] text.
When an image is being used as an `<input>` button, providing alternative text can help screen reader users understand the purpose of the button.
100
No element has a [tabindex] value greater than 0.
A value greater than 0 implies an explicit navigation ordering. Although technically valid, this often creates frustrating experiences for users who rely on assistive technologies. Learn more.
100
Cells in a <table> element that use the [headers] attribute only refer to other cells of that same table.
Screen readers have features to make navigating tables easier. Ensuring `<td>` cells using the `[headers]` attribute only refer to other cells in the same table may improve the experience for screen reader users.
100
<th> elements and elements with [role="columnheader"/"rowheader"] have data cells they describe.
Screen readers have features to make navigating tables easier. Ensuring table headers always refer to some set of cells may improve the experience for screen reader users.
ARIA Attributes Follow Best Practices
Screen readers and other assistive technologies require annotations to understand otherwise ambiguous content.
100
[aria-*] attributes match their roles.
Each ARIA `role` supports a specific subset of `aria-*` attributes. Mismatching these invalidates the `aria-*` attributes. Learn more.
100
[role]s have all required [aria-*] attributes.
Some ARIA roles have required attributes that describe the state of the element to screen readers. Learn more.
100
[role]s that require child [role]s contain them.
Some ARIA parent roles require specific roles on their children to perform their accessibility function.
100
[role]s are contained by their required parent element.
Some ARIA roles require specific roles on their parent element to perform their accessibility function.
100
[role] values are valid.
ARIA roles require specific values to perform their accessibility function.
100
[aria-*] attributes have valid values.
Assistive technologies, like screen readers, can't interpret ARIA attributes with invalid values. Learn more.
100
[aria-*] attributes are valid and not misspelled.
Assistive technologies, like screen readers, can't interpret ARIA attributes with invalid names. Learn more.
Elements Have Discernable Names
Screen readers and other assistive technologies require annotations to understand otherwise ambiguous content.
100
Buttons have an accessible name.
When a button doesn't have an accessible name, screen readers announce it as "button", making it unusable for users who rely on screen readers. Learn more.
100
Links have a discernable name.
Link text (and alternate text for images, when used as links) that is discernible, not duplicated, and focusable improves the navigating experience for screen reader users.
Elements Describe Contents Well
Screen readers and other assistive technologies require annotations to understand otherwise ambiguous content.
100
Document has a <title> element.
Screen reader users use page titles to get an overview of the contents of the page.
100
<frame> or <iframe> elements have a title.
Screen reader users rely on a frame title to describe the contents of the frame.
100
Form elements have associated labels.
Labels ensure that form controls are announced properly by assistive technologies, like screen readers. Learn more.
100
Presentational <table> elements avoid using <th>, <caption> or the [summary] attribute.
The presence of `<th>`, `<caption>` or the `summary` attribute on a presentational table may produce a confusing experince for a screen reader user as these elements usually indicates a data table.
100
<object> elements have [alt] text.
Screen readers cannot translate non-text content. Adding alt text to `<object>` elements will help a screen reader convey the meaning to a user.
100
<video> elements contain a <track> element with [kind="captions"].
When a video provides a caption it is easier for deaf and hearing impaired users to access its information.
100
<video> elements contain a <track> element with [kind="description"].
Audio descriptions provide relevant information for videos that dialogue cannot, such as facial expressions and scenes.
Elements Are Well Structured
Screen readers and other assistive technologies require annotations to understand otherwise ambiguous content.
100
<dl>'s contain only properly-ordered <dt> and <dd> groups, <script> or <template> elements.
When definition lists are not properly marked up screen readers may produce confusing or inaccurate output.
100
Definition list items are wrapped in <dl> elements.
Definition list items (<dt> and/or <dd>) wrapped in parent <dl> elements enable screen readers to properly announce content.
100
[id] attributes on the page are unique.
Unique `id=""` attributes help ensure assistive technologies do not overlook elements with the same id.
100
List items (<li>) are contained within <ul> or <ol> parent elements.
Screen readers require list items (`<li>`) to be contained within a parent `<ul>` or `<ol>` to be announced properly
Page Specifies Valid Language
Screen readers and other assistive technologies require annotations to understand otherwise ambiguous content.
100
<html> element has a [lang] attribute.
The `lang` attribute is useful for multilingual screen reader users who may prefer a language other than the default.
100
<html> element has a valid value for its [lang] attribute.
Specifying a valid BCP 47 language helps screen readers announce text properly.
100
[lang] attributes have a valid value.
Specifying a valid BCP 47 language on elements helps ensure that text is pronounced correctly by a screen reader.
Meta Tags Used Properly
Screen readers and other assistive technologies require annotations to understand otherwise ambiguous content.
100
The document does not use <meta http-equiv="refresh">.
Users do not expect a page to refresh automatically, and doing so will move focus back to the top of the page. This may create a frustrating or confusing experience
100
[user-scalable="no"] is not used in the <meta name="viewport"> element and the [maximum-scale] attribute is not less than 5.
Disabling zooming is problematic for users with low vision who rely on screen magnification to properly see the contents of a web page.
92
Best Practices
We've compiled some recommendations for modernizing your web app and avoiding performance pitfalls. These audits do not affect your score but are worth a look.
0
Uses passive listeners to improve scrolling performance
Consider marking your touch and wheel event listeners as `passive` to improve your page's scroll performance. Learn more.
View Details
URL | Location |
|---|---|
https://amp.cloudflare.com/viewer/rtv/011-4-71/amp-viewer.js | line: 1 |
https://amp.cloudflare.com/viewer/rtv/011-4-71/amp-viewer.js | line: 1 |
chrome-extension://aadgmnobpdmgmigaicncghmmoeflnamj/ng-inspector.js | line: 338 |
View 11 passed items
100
Avoids Application Cache
Application Cache has been deprecated by Service Workers. Consider implementing an offline solution using the Cache Storage API.
100
Avoids WebSQL DB
Web SQL is deprecated. Consider using IndexedDB instead. Learn more.
100
Uses HTTPS
All sites should be protected with HTTPS, even ones that don't handle sensitive data. HTTPS prevents intruders from tampering with or passively listening in on the communications between your app and your users, and is a prerequisite for HTTP/2 and many new web platform APIs. Learn more.
100
Uses HTTP/2 for its own resources
HTTP/2 offers many benefits over HTTP/1.1, including binary headers, multiplexing, and server push. Learn more.
100
Avoids Mutation Events in its own scripts
Mutation Events are deprecated and harm performance. Consider using Mutation Observers instead. Learn more.
100
Avoids document.write()
For users on slow connections, external scripts dynamically injected via `document.write()` can delay page load by tens of seconds. Learn more.
100
Opens external anchors using rel="noopener"
Open new tabs using `rel="noopener"` to improve performance and prevent security vulnerabilities. Learn more.
100
Avoids requesting the geolocation permission on page load
Users are mistrustful of or confused by sites that request their location without context. Consider tying the request to user gestures instead. Learn more.
100
Avoids requesting the notification permission on page load
Users are mistrustful of or confused by sites that request to send notifications without context. Consider tying the request to user gestures instead. Learn more.
100
Avoids deprecated APIs
Deprecated APIs will eventually be removed from the browser. Learn more.
100
Manifest's short_name won't be truncated when displayed on homescreen
Make your app's `short_name` less than 12 characters to ensure that it's not truncated on homescreens. Learn more.