rhetenor/awesome-awesomeness
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Updating conversion, creating readmes

Browse Source
This commit is contained in:
Jonas Zeunert
2024-04-19 23:37:46 +02:00
parent 3619ac710a
commit 08e75b0f0a
635 changed files with 30878 additions and 37344 deletions
Download Patch File Download Diff File Expand all files Collapse all files

66
terminal/pagespeedmetrics
View File

@@ -1,4 +1,4 @@
 Awesome Page Speed Metrics !Awesome (https://awesome.re/badge.svg) (https://awesome.re)
 Awesome Page Speed Metrics !Awesome (https://awesome.re/badge.svg) (https://awesome.re)
▐ Metrics to help understand page speed and user experience.
@@ -47,8 +47,7 @@
Make a request to your page with a tool and evaluate performance. Be sure to make it realistic (e.g. by throttling network and CPU) and reduce noise (e.g. by running multiple times).
- Lighthouse (https://developers.google.com/web/tools/lighthouse/) - A tool built on Google Chrome to audit web pages. You can run it from Chrome DevTools, a Chrome Extension or from the command line (even with 
headless Chrome).
- Lighthouse (https://developers.google.com/web/tools/lighthouse/) - A tool built on Google Chrome to audit web pages. You can run it from Chrome DevTools, a Chrome Extension or from the command line (even with headless Chrome).
- Google PageSpeed Insights (https://developers.google.com/speed/pagespeed/insights/) - Free and hosted Lighthouse reporting (and more) by Google.
- WebpageTest (https://www.webpagetest.org/) - Free and hosted web performance testing (also an open source project).
- Sitespeed.io (https://www.sitespeed.io/) - A set of open source performance monitoring tools.
@@ -57,12 +56,11 @@
- SpeedCurve (https://speedcurve.com/) - Web performance monitoring SaaS.
- AwesomeTechStack (https://awesometechstack.com/) - Website awesomeness monitoring Tool.
―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
Field Data (Real User Monitoring - RUM)
Collect performance data from real users visiting your page. Be mindful of the actual overhead, as it runs in your user's browser and watch out for browser support of more recent metrics (e.g. compared to your 
user-base).
Collect performance data from real users visiting your page. Be mindful of the actual overhead, as it runs in your user's browser and watch out for browser support of more recent metrics (e.g. compared to your user-base).
- Performance tracking with Google Analytics (GA) (https://philipwalton.com/articles/the-google-analytics-setup-i-use-on-every-site-i-build/#performance-tracking)
- Chrome User Experience Report (CrUX) (https://developers.google.com/web/tools/chrome-user-experience-report/)
@@ -76,8 +74,8 @@
Critical rendering path
The critical rendering path is everything that happens between receiving network bytes and rendering something on the screen. To optimize any rendering metrics like First Contentful Paint (FCP) 
(#first-contentful-paint-fcp) or Speed Index (#speed-index) you have to understand how the critical rendering path works.
The critical rendering path is everything that happens between receiving network bytes and rendering something on the screen. To optimize any rendering metrics like First Contentful Paint (FCP) (#first-contentful-paint-fcp) or Speed 
Index (#speed-index) you have to understand how the critical rendering path works.
- Critical rendering path (https://developers.google.com/web/fundamentals/performance/critical-rendering-path/)
@@ -87,8 +85,7 @@
A user perceives any visual change within 100ms as instant. Any task blocking the Main Thread by taking longer than 50ms is considered a long task (as it might make the browser unresponsive to user input).
To optimize interactivity metrics like Total Blocking Time (TBT) (#total-blocking-time-tbt) and First Input Delay (FID) (#first-input-delay-fid) you have to understand long tasks and how to avoid them as much as
possible.
To optimize interactivity metrics like Total Blocking Time (TBT) (#total-blocking-time-tbt) and First Input Delay (FID) (#first-input-delay-fid) you have to understand long tasks and how to avoid them as much as possible.
- Spec - Long Tasks (https://w3c.github.io/longtasks/)
- Blogpost - Tracking CPU with Long Tasks API (https://calendar.perfplanet.com/2017/tracking-cpu-with-long-tasks-api/)
@@ -103,14 +100,14 @@
- Is it usable - Can users interact with the page, or is it still busy loading? (e.g TBT (https://github.com/csabapalfi/awesome-web-performance-metrics/#total-blocking-time-tbt))
- Is it delightful/smooth? - Are the interactions smooth and natural, free of lag and jank?
―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
Rendering metrics
First Contentful Paint (FCP)
The First Contentful Paint (FCP) metric measures the time from when the page starts loading to when any part of the page's content is rendered on the screen. For this metric, "content" refers to text, images 
(including background images),  elements.
The First Contentful Paint (FCP) metric measures the time from when the page starts loading to when any part of the page's content is rendered on the screen. For this metric, "content" refers to text, images (including background 
images),  elements.
- Lab: Lighthouse
- Field: Chrome 60+, CrUX
@@ -128,8 +125,8 @@
Cumulative Layout Shift (CLS)
 A layout shift occurs any time a visible element changes its position from one frame to the next. CLS measures the sum total of all individual layout shift scores for every unexpected layout shift that occurs 
during the entire lifespan of the page.
 A layout shift occurs any time a visible element changes its position from one frame to the next. CLS measures the sum total of all individual layout shift scores for every unexpected layout shift that occurs during the entire lifespan
of the page.
- Lab: Lighthouse/WPT
- Field: Chrome 77+
@@ -138,8 +135,8 @@
Visually Complete
The Visually Complete is the time from the start of the initial navigation until the visible (above the fold) part of your page is no longer changing. (e.g. WPT measures this using a color histogram of the page 
based on video/screenshots recording).
The Visually Complete is the time from the start of the initial navigation until the visible (above the fold) part of your page is no longer changing. (e.g. WPT measures this using a color histogram of the page based on 
video/screenshots recording).
- Lab: WPT
- Field: N/A
@@ -147,8 +144,8 @@
Speed Index
Speed Index shows how quickly the contents of a page are visibly populated (lower numbers are better). This is done by frequently measuring visual completeness during loading. The quicker the page is more 
visually complete the lower the value.
Speed Index shows how quickly the contents of a page are visibly populated (lower numbers are better). This is done by frequently measuring visual completeness during loading. The quicker the page is more visually complete the lower the
value.
- Lab: Lighthouse, WPT (but slightly different spec)
- Field: N/A
@@ -166,14 +163,14 @@
- Spec - Element Timing API (https://wicg.github.io/element-timing/)
- Blogpost - Hero Element Timing - SpeedCurve (https://speedcurve.com/blog/web-performance-monitoring-hero-times/)
―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
Interactivity metrics
Time to Interactive (TTI)
Time to interactive is the time it takes for the page to become fully interactive (as in Main Thread quiet for 5s). Sometimes called Consistently Interactice and not to be confused with First Interactive or 
First CPU Idle. (Warning: one of the most confusing and misunderstood metrics).
Time to interactive is the time it takes for the page to become fully interactive (as in Main Thread quiet for 5s). Sometimes called Consistently Interactice and not to be confused with First Interactive or First CPU Idle. (Warning: one
of the most confusing and misunderstood metrics).
- Lab: Lighthouse, WPT
- Field: Not recommended as users interacting with your page can skew field measurements of TTI
@@ -183,8 +180,7 @@
Total Blocking Time (TBT)
The Total Blocking Time (TBT) metric measures the total amount of time between First Contentful Paint (FCP) and Time to Interactive (TTI) where the main thread was blocked for long enough to prevent input 
responsiveness.
The Total Blocking Time (TBT) metric measures the total amount of time between First Contentful Paint (FCP) and Time to Interactive (TTI) where the main thread was blocked for long enough to prevent input responsiveness.
- Lab: Lighthouse
- Field: N/A
@@ -192,8 +188,8 @@
First Input Delay (FID)
First Input Delay (FID) measures the time from when a user first interacts with your site to the time when the browser is actually able to respond to that interaction. An interaction can be when users click a 
link, tap on a button, or use a custom, JavaScript-powered control.
First Input Delay (FID) measures the time from when a user first interacts with your site to the time when the browser is actually able to respond to that interaction. An interaction can be when users click a link, tap on a button, or 
use a custom, JavaScript-powered control.
- Lab: N/A (as it requires the user to interact with the page)
- Field: IE9+ (and Safari, Chrome, Firefox) (with polyfill - 0.4KB)
@@ -208,12 +204,11 @@
- Field: N/A
- Docs - Max Potential FID - web.dev (https://web.dev/lighthouse-max-potential-fid/)
―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
Network metrics
Network timing field data can uncover a non-optimized TLS setup, slow DNS lookups or server side processing and issues with CDN configuration. See also a separate section about measuring transferred bytes 
(#transferred-bytes).
Network timing field data can uncover a non-optimized TLS setup, slow DNS lookups or server side processing and issues with CDN configuration. See also a separate section about measuring transferred bytes (#transferred-bytes).
- Blogpost - Navigation and Resource Timing (https://developers.google.com/web/fundamentals/performance/navigation-and-resource-timing/)
- Spec - Navigation Timing (https://www.w3.org/TR/navigation-timing-2/)
@@ -253,8 +248,7 @@
Transferred bytes
You can measure the byte weight of your assets with a number of tools. You would normally track these Lab only as the numbers are usually the same in the Field (but be mindful of device type or geographical 
location specific pages).
You can measure the byte weight of your assets with a number of tools. You would normally track these Lab only as the numbers are usually the same in the Field (but be mindful of device type or geographical location specific pages).
Measuring own (and third-party) JavaScript bytes is crucial as JavaScript is the main cause of high TTI (#time-to-interactive-tti) or FID (#first-input-delay-fid) values.
@@ -265,7 +259,7 @@
- Can You Afford It?: Real-world Web Performance Budgets (https://infrequently.org/2017/10/can-you-afford-it-real-world-web-performance-budgets/)
- Which third party scripts are most excessive (https://github.com/patrickhulce/third-party-web)
―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
Other metrics
@@ -277,8 +271,8 @@
User Timing
The User Timing API allows the developer to create application specific timestamps that are part of the browser's performance timeline. e.g. you can create a user timing mark to measure when your JS has loaded 
for a specific component on the page.
The User Timing API allows the developer to create application specific timestamps that are part of the browser's performance timeline. e.g. you can create a user timing mark to measure when your JS has loaded for a specific component 
on the page.
- Lab: Lighthouse, WPT
- Field: IE 10+, Safari 11+ (and Chrome, Firefox of course)
@@ -292,8 +286,8 @@
Frame rate
 The frame rate is the frequency at which the browser can display frames. A frame represents the amount of work a browser does in one event loop iteration such as processing DOM events, resizing, scrolling, 
rendering, CSS animations, etc. A frame rate of 60 fps (frames per second) is a common target for a good responsive user experience. This means the browser should process a frame in about 16.7 ms.
 The frame rate is the frequency at which the browser can display frames. A frame represents the amount of work a browser does in one event loop iteration such as processing DOM events, resizing, scrolling, rendering, CSS animations, 
etc. A frame rate of 60 fps (frames per second) is a common target for a good responsive user experience. This means the browser should process a frame in about 16.7 ms.
- Lab: Chrome and FF Devtools
- Field: No browser implements the Frame Timing API yet but you can roll your own fps meter using requestAnimationFrame