WDD 231: Web Frontend Development I

W05 Learning Activity: UX – Page Performance

Overview

As a web developer, creating beautiful, standards-based pages is just the beginning. To be effective, your site must also perform well and offer a great user experience (UX).

This learning activity introduces the key questions and metrics you should consider as you design your site to optimize for better performance. Focusing on this performance data will equip you to enhance the overall user experience and engagement.

Prepare

When users visit a page, their experience can be broken down into four core questions:

1. Is it happening?
   • Did the navigation start successfully? Has the server responded?
   • At this stage, users want to know something is happening. They have clicked a link and landed on the page and want to see that it is responding. A delay here can feel like the site is broken.
2. Is it useful?
   • Has enough content rendered that users can see and engage with the content?
   • Moving beyond simply knowing that the page has started loading, users want to be able to see meaningful content quickly. If they can't, they may get frustrated and leave the page.
3. Is it usable?
   • Can users interact with the page, or is it still busy or unresponsive?
   • If the page has visually loaded, it might look ready, but if buttons don't work or the page freezes, it's not usable.
4. Is it delightful?
   • Are interactions smooth and natural and free of lag?
   • This stage is about polish. Smooth animations and responsive interactions make the experience feel high-quality and enjoyable. If content jumps around or lags, the site feels unprofessional.

Performance Metrics

To answer the above questions in a measurable way, web developers use web performance metrics. Google groups three of them, LCP, INP, and CLS, as the Core Web Vitals. Here are four key metrics:

• First Contentful Paint (FCP)
  • What it is: Time from when navigation starts to when any content first appears (including text or images).
  • Why it matters: Gives the user confidence that something is happening.
• Largest Contentful Paint (LCP)
  • What it is: Time until the largest visible content element (usually an image or a big text block) appears. A good score is 2.5 seconds or less.
  • Why it matters: Helps determine when the main content is visible and useful.
• Interaction to Next Paint (INP)
  • What it is: How long the page takes to visibly respond after the user clicks, taps, or presses a key. A good score is 200 milliseconds or less.
  • Why it matters: Tells you whether the page is usable or is still busy and unresponsive.
• Cumulative Layout Shift (CLS)
  • What it is: A score that represents how much the layout unexpectedly shifts while loading. A good score is 0.1 or less.
  • Why it matters: Shifts can cause users to click the wrong thing or feel disoriented.

User Perception

In addition to the metrics above, it is important to consider the perception of the user as well. A fast page that feels awkward can still create frustration, and a slightly slower page that feels smooth might result in a better experience. With this in mind, it is important to consider both:

• The objective data (such as the metrics mentioned above)
• The subjective experience (smoothness, flow, and user feedback)

Lighthouse Tools

Throughout this course and previous courses, you have used the Google Lighthouse tool, which is integrated into DevTools. This tool generates reports on performance metrics, as well as accessibility, best practices, and Search Engine Optimization (SEO). You have already been running this tool and it is used in many of the assignment rubrics.

The following are some of the principles and specific diagnostic methods you have been using throughout this and previous courses to improve performance and the overall user experience:

• Optimize images, properly size images, and consider next-generation image formats such as WebP and AVIF.
• Set an explicit width and height on images and embeds to reduce layout shifts and improve CLS.
• Defer offscreen images and content, including using lazy loading for images below the fold.
• Use efficient caching and a content delivery network (CDN).
• Minimize render-blocking JavaScript and CSS.
• Avoid excessive DOM sizes.
• Reduce unused CSS and unused JavaScript.
• Reduce the scope and complexity of style calculations.
• Test on a variety of real devices and network conditions.

Activity Instructions

In this activity you will evaluate the performance of the Church's website using the Lighthouse tools.

1. In your browser, start an incognito window or private browsing session so extensions and cached files do not skew the results.
2. Go to the Church's former address, https://lds.org.

   Notice that the server redirects you to https://www.churchofjesuschrist.org. Redirects add time before the page starts loading.
   (In addition, your preferred language parameter may be part of the URL's query string with a name-value pair, e.g., ?lang=es)

3. Estimate how long the page took to render the actionable Sign In button from your end-user perspective.
4. Open the browser's DevTools on this page to check the performance using metrics.
5. Run an audit on the page by using the Performance tab and clicking the reload button.

   

   

6. Use the screenshot timeline to find out how long it took to finally render the Sign In button. You can do this visually.

   

7. Using the Lighthouse tool, select the Mobile device and turn on the Performance category and then click Analyze page load.
8. Review the Performance metrics and the diagnostics.
   Is there anything that you might suggest as low-hanging fruit to fix?
9. Post one finding and your suggested fix in Microsoft Teams.
10. Evaluate your own work by running the same audits on your own pages.