generated from adobe/aem-boilerplate
-
Notifications
You must be signed in to change notification settings - Fork 4
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
fac5aa2
commit 2f856fc
Showing
2 changed files
with
60 additions
and
82 deletions.
There are no files selected for viewing
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,133 +1,111 @@ | ||
| # Perfomance | ||
|
|
||
| So we want to improve the overall performance on EDS. | ||
| # Performance Optimization for EDS | ||
|
|
||
| ## Edge Delivery | ||
|
|
||
| Edge delivery scripts have those premises in mind: | ||
| In our pursuit of enhancing overall performance on EDS, we focus on optimizing Edge Delivery scripts. The guiding principles are as follows: | ||
|
|
||
| 1. Eager (Priotize main files, style.css, script.js, etcs) | ||
| 2. Lazy (queue the second priority) | ||
| 3. Delay (Delay other code) | ||
| 1. **Eager Loading:** Prioritize critical files such as `main files`, `style.css`, and `script.js`. | ||
| 2. **Lazy Loading:** Queue secondary priority items. | ||
| 3. **Delay Loading:** Postpone non-essential code execution. | ||
|
|
||
| You can check more in [](../edge/perfomance.md) | ||
| Explore more details [here](../edge/performance.md). | ||
|
|
||
| ## Assumptions | ||
| As state in [Keeping It 100, Web Performance | ||
| ](https://www.aem.live/developer/keeping-it-100#three-phase-loading-e-l-d) | ||
| ```It is a good rule of thumb to keep the aggregate payload before the LCP is displayed below 100kb, which usually results in an LCP event quicker than 1560ms (LCP scoring at 100 in PSI). Especially on mobile the network tends to be bandwidth constrained, so changing the loading sequence before LCP has minimal to no impact.``` | ||
| ## Assumptions | ||
|
|
||
| That actually is a key factor to good LCP and loading. | ||
| And we would call it perfomance __BUDGET__ and queueing should influence that. | ||
| As highlighted in [Keeping It 100, Web Performance](https://www.aem.live/developer/keeping-it-100#three-phase-loading-e-l-d): | ||
|
|
||
| > "It is a good rule of thumb to keep the aggregate payload before the LCP below 100kb, resulting in an LCP event quicker than 1560ms (LCP scoring at 100 in PSI). Especially on mobile, the network tends to be bandwidth constrained, so changing the loading sequence before LCP has minimal to no impact." | ||
| # OOB Implementation Queue. | ||
| This underscores the significance of adhering to a performance budget and how queuing influences it. | ||
|
|
||
| Base on that premise, we should avoid by default having too much assets and scripts loaded in the main priority | ||
| But at the same time queuing those endups removing the benefits of concurency among other things | ||
| # OOB Implementation Queue | ||
|
|
||
| ### Default bootstrap script | ||
| In line with the performance budget, we default to minimizing assets and scripts in the main priority. However, indiscriminate queuing can negate the benefits of concurrency and other optimizations. | ||
|
|
||
|  | ||
| ### Default Bootstrap Script | ||
|
|
||
| Here we have the example of the impact of queueing under this page load. | ||
|  | ||
|
|
||
| Where you can see several assets are queue before even the FCP and LCP | ||
| The impact of queuing during page load is evident here, where multiple assets queue before FCP and LCP, leading to conflicts, delays, and potential CLS issues. | ||
|
|
||
| 1. DOMContentLoaded and Load event conflict | ||
| 2. That counts that all LCP script should be at style.css | ||
| 3. We have several ms between FCP and LCP, and that opens a window of CLS | ||
| 4. loading is "strech" for several milliseconds before LCP | ||
|  | ||
|
|
||
| That becames clear when slow network is applyed | ||
| Queuing's impact becomes more pronounced on a slow network. | ||
|
|
||
|  | ||
| ## Checking Concurrency and Delaying | ||
|
|
||
| Queuing impact now is quite clear. | ||
| Examining three key hypotheses: | ||
|
|
||
| 1. Concurrency yields better results. | ||
| 2. Resolving Load and DOMContentLoaded conflicts is beneficial. | ||
| 3. Concurrency with the three-phase approach improves performance. | ||
|
|
||
| ## Checking concurency and delaying | ||
| Explore additional examples in [EDS performance](../edge/performance.md). | ||
|
|
||
| So having the same rule of thumb of a perfomance budget for LCP under 100kb, let's check 3 main hipotesis. | ||
| ## Concurrency, Load, and Keeping Three Phases | ||
|
|
||
| 1. Concurrency would be better | ||
| 2. Solving Load and DOMContentLoaded conflict should be solve | ||
| 3. Using concurrency but keeping 3 fases improve perfomance | ||
| Improving performance by leveraging concurrency, optimizing load, and retaining the three-phase structure. | ||
|
|
||
| Other examples on EDS perfonmance can be found [here](../edge/perfomance.md) | ||
|  | ||
|  | ||
|
|
||
| ## Concurrency, Load and keeping 3 fases. | ||
| Notable improvements include reduced overall load times and LCP, especially on slow networks. | ||
|
|
||
| We can improve perfomance by concurrency load and keeping the 3 fases | ||
| Scripts will keep the 3 phases defined in EDGE but with better concurency | ||
| ## Concurrency, Load, and Removing Three Phases | ||
|
|
||
| Let's see the example | ||
| __Regular network__ | ||
|  | ||
| __slow network__ | ||
|  | ||
| Prioritizing loading without enforcing delays, focusing on LCP components, and allowing other items to load concurrently. | ||
|
|
||
| Here we already can see 2 improvements | ||
|  | ||
|  | ||
|
|
||
| 1. Concurrency reduce the overall load time and LCP, both in regular and slow networks | ||
| 2. DOMContentLoaded fired during html resources parse ends, then at Load event is fired after the EAGER phase | ||
| Significant performance gains, particularly with enhanced concurrency and correct firing of DOMContentLoaded and Load events. | ||
|
|
||
| ## Concurrency, Load and removing 3 fases. | ||
| # Conclusion | ||
|
|
||
| In this example we don't force delay we just priorize loading to in case of stalled loading. | ||
| Opting for regular prioritization and concurrency loading yields superior gains, aligning with the established performance budget guideline. | ||
|
|
||
| 1 - Priorize LCP defined ones | ||
| 2 - Allow other things on the page to load toguether at the end of prio | ||
| ## Further Improvements | ||
|
|
||
| __Regular network__ | ||
|  | ||
| __slow network__ | ||
|  | ||
| - **Editorial Control Over LCP (Largest Contentful Paint):** Empowering editors to specify components for LCP on each page. | ||
| - **Selective Eager Loading of Images:** Providing the ability to load images eagerly based on editorial preferences and performance considerations. | ||
|
|
||
| # Editorial Control Over LCP | ||
|
|
||
| So here we can find a even better perfomance. | ||
| Given the diverse templates and components on pages, editorial control over LCP becomes crucial. | ||
|
|
||
| 1. More cucurrency improves the overall perfomance and LCP | ||
| 2. DOMContentLoaded fired correcly and load fires correcly on complete of the page. | ||
| 3. Just priorizing loading into LCP components but let other load offer better gains specially on slow networks. | ||
| 1. Select the number of images to prioritize. | ||
| 2. Define components to prioritize for LCP. | ||
|
|
||
| ## Metadata for LCP and Eager Images | ||
|
|
||
| # conclusion | ||
| Define LCP components and eager-loading images in metadata. | ||
|
|
||
| So we choose the regular priorizing and concurrency load that would offer better gains, specially if we follow the | ||
| ```It is a good rule of thumb to keep the aggregate payload before the LCP is displayed below 100kb, which usually results in an LCP event quicker than 1560ms (LCP scoring at 100 in PSI). Especially on mobile the network tends to be bandwidth constrained, so changing the loading sequence before LCP has minimal to no impact.``` | ||
|  | ||
|
|
||
| # Editorial Control Over LCP | ||
| 1. **lcp:** Comma-separated component/block names. | ||
| 2. **eager-images:** Number of images for eager loading. | ||
|
|
||
| So many pages can have diferent templates and components and sometimes that can Impact the LCP. | ||
| ## Defining LCP Components | ||
|
|
||
| 1 - We want to be able to select how many images would be priorized. | ||
| 2 - We want to define what components should be priorized to LCP | ||
| Without defining LCP, components load in order of appearance. | ||
|
|
||
| ## meta data to defined LCP and Eager images | ||
| We can define what components should be priorized at metadata | ||
|  | ||
|  | ||
|
|
||
| 1. lcp, comma-separeted components/block names | ||
| 2. eager-images, number of images that should have loading eager | ||
| After setting up LCP order (`theme, header, navigation`): | ||
|
|
||
| ## Defining LCP components | ||
|  | ||
|
|
||
| Here it's a example without defining a LCP, | ||
| It loads by order of aperence | ||
|  | ||
| 1. Notice that the navigation component is under the header component | ||
| 2. It's load at the end of the queue since it's the last aperance (html loads, header loads, then navigation apears, navigation loads) | ||
| Now you can: | ||
|
|
||
| Now let's add the LCP in this order | ||
| - `header, theme, navigation` | ||
| 1. Establish the order of loading. | ||
| 2. Prioritize components for loading as priority 1. | ||
|
|
||
|  | ||
| ## Defining Eager Images | ||
|
|
||
| Let's check the loading diference | ||
|  | ||
| Introducing eager loading for the first hero image using metadata. | ||
|
|
||
|  | ||
|
|
||
| Preview of the result: | ||
|
|
||
| - **Editorial Control Over LCP (Largest Contentful Paint):** Allowing editors to specify which components serve as the largest contentful paint on each page. | ||
| - **Selective Eager Loading of Images:** Providing the capability to selectively load images eagerly based on editorial preferences and performance considerations. | ||
|  |