Optimize WKND Adventures Page: Fix INP Issue

by Editorial Team 45 views
Iklan Headers

Hey guys! We've got a bit of a snag with the WKND Adventures page (https://publish-p165653-e1774234.adobeaemcloud.com/wknd-deck/us/en/adventures.html) and its Interaction to Next Paint (INP) score. Basically, the page isn't as snappy as it could be, and we need to fix it! Let's dive into the details and see how we can make this page super smooth.

CWV Issue: INP

Page URL: https://publish-p165653-e1774234.adobeaemcloud.com/wknd-deck/us/en/adventures.html

Description: The Interaction to Next Paint (INP) metric measures the time it takes for a page to respond to user interactions. A high INP indicates that the page is slow to respond, leading to a poor user experience. This document outlines two key strategies to address and mitigate the INP issue on the WKND Adventures page. By implementing these recommendations, we can significantly improve the page's responsiveness and overall performance. The strategies focus on optimizing JavaScript execution and reducing blocking times to ensure a smoother and more engaging user experience.

1. Disable or Defer AEM ContextHub

AEM ContextHub: The Culprit Behind the Delay. Guys, AEM ContextHub, which is used for website personalization, is causing a major headache. It's freezing the page for over 1.5 seconds during loading! This prevents users from interacting with the content and delays when they see the main image. If we're not actively using personalization on this page, disabling ContextHub is the single most impactful fix to boost site speed and responsiveness. Think of it like this: ContextHub is like a fancy tool that's great when you need it, but if you're not using it, it's just weighing you down. Disabling it is like taking off a heavy backpack, making the page load faster and feel much more responsive.

Implementation Priority: High

Implementation Effort: Easy

Expected Impact:

  • INP: Resolves the primary cause of poor INP, reducing blocking time by over 1000ms. That's a whole second! Imagine how much faster the page will feel.
  • LCP: Improves LCP by over 500ms by removing a large, blocking JavaScript file from the initial loading path. LCP, or Largest Contentful Paint, measures how long it takes for the main content of the page to load. By removing this blocking file, we're making sure that users see the important stuff much faster.

Implementation Deets:

  1. Validate Usage: First things first, double-check with the business and marketing teams if they're actually using the personalization features powered by ContextHub on this template. In many AEM setups, it's enabled by default but never really used. It's like having a spare tire in your car that you never check – you might not even need it!

  2. Disable if Unused (Recommended): The best way to handle this is to disable it at the template level. Here's how:

    • In the AEM editor, go to the Editable Template (/conf/wknd/settings/wcm/templates/).
    • Open the page template's properties.
    • Go to the "Policies" tab.
    • Edit the policy for the root container.
    • In the policy settings, make sure the ContextHub path is set to "Disabled".

  3. Defer if Required (Alternative): If we absolutely have to use ContextHub, we should load its script tag non-blockingly. Find where the script is included in the page's HTL and add the defer attribute. This tells the browser to load the script in the background without blocking the rest of the page from loading.

    Here's the code snippet:

    <!-- Change this in your page's head.html or customheaderlibs.html -->
<script src="/etc/cloudsettings.kernel.js/conf/wknd/settings/cloudsettings/default/contexthub" type="text/javascript"></script>

<!-- To this -->
<script src="/etc/cloudsettings.kernel.js/conf/wknd/settings/cloudsettings/default/contexthub" type="text/javascript" defer></script>

2. Split JavaScript into Component-Specific Clientlibs

JavaScript Optimization: Load Only What You Need. Alright, so right now, the site loads one giant JavaScript file that has code for every interactive feature on the entire website. That's like carrying your entire toolbox with you when you only need a screwdriver! We're going to break this file up, so the page only loads the specific JavaScript needed for the components it's actually using. This will seriously reduce initial load time and make the page way more responsive. By creating separate client libraries for each component, we ensure that only the necessary JavaScript code is loaded, minimizing the initial load time and improving overall performance.

Implementation Priority: Low

Implementation Effort: Hard

Expected Impact:

  • INP: Reduces blocking time by 150-250ms, further improving responsiveness. Every millisecond counts!
  • LCP: Secondary improvement of ~100ms because there's less main-thread contention. The main thread is where all the action happens, so reducing contention means things can run more smoothly.

Implementation Deets:

  1. Refactor Monolithic ClientLib: Take a look at the main clientlib-site.js and figure out which code belongs to specific AEM components (like Carousel, Tabs, or Accordion).

  2. Create Component-Level ClientLibs: For each complex component, create its own JavaScript clientlib (e.g., wknd.components.carousel). This keeps things organized and modular.

  3. Include in Component HTL: In the component's HTL file, include its dedicated clientlib. This makes sure the JS is only loaded when the component is on the page. Use the defer attribute to prevent blocking.

    Here's an example:

    <!-- In /apps/wknd/components/carousel/carousel.html -->
<sly data-sly-call="${clientlib.js @ categories='wknd.components.carousel', loading='defer'}"></sly>

Note: A pull request with the fix will be created automatically. Let's get this done, team!