My progress
Menu

Digital Marketing · Focus area 1: Technical SEO

DM3: Site speed, Core Web Vitals and the technical audit

Goal: measure how fast and stable pages feel to real visitors, find what slows them down (heavy scripts, images, third-party tags), fix the biggest problems, and run a technical SEO audit that ranks fixes by impact.

You'll need: DM1, DM2, Module 16 (Responsive Websites), Module 19 (Browser Interactions), Module 39 (Frontend Quality), and the MittiMart practice kit.

Where this is used: most Indian shoppers browse on phones, often on budget handsets and patchy mobile data. A page that takes eight seconds to show anything loses people before they see a product, and search engines use page experience as one of many signals.

How it differs: frontend developers build speed into the code. Marketers add tags, pixels, chat widgets and sliders that can undo that work. This module is about measuring the cost of what marketing adds, and deciding what's worth it.

Time: reading about 2½ hours · practice (the Try it tasks) about 2½ hours · assignment about 3½ hours.

Lessons

  1. 1Why speed matters, and how to measure itReading 15–25 minutes, plus practice✓
  2. 2Core Web Vitals: LCP, INP and CLSReading 15–25 minutes, plus practice✓
  3. 3Page weight, blocking scripts and third-party tagsReading 15–25 minutes, plus practice✓
  4. 4Images, fonts and mobile-first pagesReading 15–25 minutes, plus practice✓
  5. 5Running a technical SEO auditReading 15–25 minutes, plus practice✓

🛠️Assignment: Make MittiMart light and write the audit

  1. Measure the starter home page's total download and list the three largest files.
  2. Remove the slider library and add defer to the other scripts; measure again.
  3. Check every page against the audit checklist in Lesson 5 and record the issues in seo/audit.md in the format in seo/README.md.
  4. Rank the issues by severity and effort, fix them, and set each status.
  5. Add the search traffic figures from seo/search-console.csv and write the Limits section.

Self-check before you finish:

✅Module check

Explain in a few sentences, in your own words:

How do you find and fix what makes pages slow, and run a technical audit a team will act on?

Show a good answer

A good answer mentions: lab and field measurements tested like real visitors (a mid-range phone on 4G); LCP (2.5 s), INP (200 ms) and CLS (0.1) at the 75th percentile, and a common cause of each; render-blocking scripts fixed with defer, async or the end of the body; page weight and big libraries; third-party tags reviewed for owner, purpose, consent and cost; image formats, sizes, width and height, and lazy loading below the first screen only; mobile-first indexing; and an audit that records issues with pages, severity, fix and status, ordered by impact and effort, verified, and reported with honest limits.

📚Official references

Official documentation and guidance for this module's topics, chosen on 2 November 2026. Tools, laws and standards change, so check the current version before you rely on a detail. If a link has moved, search the same site.

📝Module quiz

10 questions · 10 marks each · 100 marks in all · pass mark 70% · retry as often as you like ·

1. A team's speed test shows a score of 95 on the office laptop, but field data says most phone visitors wait over 4 seconds. Which is

Why each option is right or wrong

  • “The laptop test, because it's run in controlled conditions every time” (Incorrect): Controlled isn't the same as typical; the conditions differ from customers'.
  • “Neither, because speed tests can't measure what customers feel at all” (Incorrect): Both measure useful things; field data is closer to experience.
  • “An average of the two figures, to balance office and customers” (Incorrect): Averaging different kinds of measurement doesn't mean anything.
  • “The field data, as it comes from real visitors' devices and networks” is correct.

    Field data reflects real phones and connections, at the 75th percentile.

    • Then: reproduce it in a lab with a throttled phone.
    • Find: the cause in the Network tab.

📖 Revise: Lesson 1: Why speed matters, and how to measure it

Question ID sp-digital-marketing-03-q1 · Report a mistake in this question
2. A product page's text jumps down when a cookie banner appears after two seconds. Which Core Web Vital does this hurt?

Why each option is right or wrong

  • “Largest Contentful Paint, as the banner delays the largest element” (Incorrect): The page has already shown; the problem is movement.
  • “Interaction to Next Paint, as people tap the wrong place” (Incorrect): Taps may go wrong, but the measure of movement is CLS.
  • “Time to First Byte, as the server sends the banner late” (Incorrect): The server isn't the cause of the movement.
  • “Cumulative Layout Shift, as visible content moves unexpectedly” is correct.

    Late content pushing the page down is a layout shift.

    • Fix: reserve space or overlay the banner.
    • Good: 0.1 or less.

📖 Revise: Lesson 2: Core Web Vitals: LCP, INP and CLS

Question ID sp-digital-marketing-03-q2 · Report a mistake in this question
3. Which INP value counts as good?

Why each option is right or wrong

  • “2.5 seconds or less, the same as for LCP” (Incorrect): 2.5 seconds is the LCP threshold.
  • “0.1 or less, measured in seconds across the visit” (Incorrect): 0.1 is the CLS threshold, and it isn't in seconds.
  • “1 second or less for the first tap, ignoring later ones” (Incorrect): INP looks across the visit, and the threshold is lower.
  • “200 milliseconds or less, at the 75th percentile of visits” is correct.

    INP measures response to taps and clicks; 200 ms or less is good.

    • Cause of slow INP: heavy JavaScript.
    • Replaced: First Input Delay in 2024.

📖 Revise: Lesson 2: Core Web Vitals: LCP, INP and CLS

Question ID sp-digital-marketing-03-q3 · Report a mistake in this question
4. A shop's pages load a 500 KB slider library in the <head> to rotate three images on the home page. What's the best fix?

Why each option is right or wrong

  • “Keep it, and move it lower in the <head> so it loads a bit later” (Incorrect): It still blocks the page wherever it is in the head.
  • “Add async, so every page still downloads the full library quickly” (Incorrect): It stops blocking, but every page still downloads 500 KB it doesn't use.
  • “Load the library twice, once early and once late, to be safe” (Incorrect): That doubles the cost.
  • “Drop the slider, or replace it with a few lines, and defer the other scripts” is correct.

    Removing the weight solves the problem at its source.

    • Kit: about 509 KB down to about 12 KB.
    • Ask: what is the slider for?

📖 Revise: Lesson 3: Page weight, blocking scripts and third-party tags

Question ID sp-digital-marketing-03-q4 · Report a mistake in this question
5. What does defer on a script do?

Why each option is right or wrong

  • “Stops it running until the visitor clicks somewhere on the page” (Incorrect): That would be a different, custom behaviour.
  • “Runs it before anything else so the page is ready sooner” (Incorrect): That's what a blocking script does.
  • “Loads it only on the visitor's second visit to the site” (Incorrect): Defer has nothing to do with repeat visits.
  • “Downloads it alongside the HTML and runs it in order once the HTML is read” is correct.

    Deferred scripts don't block the page and keep their order.

    • Compare: async runs as soon as ready, in any order.
    • Use: most site scripts.

📖 Revise: Lesson 3: Page weight, blocking scripts and third-party tags

Question ID sp-digital-marketing-03-q5 · Report a mistake in this question
6. A tag manager holds 38 tags. Nobody can explain 14 of them. What should happen first?

Why each option is right or wrong

  • “Keep them all in place, as removing tags might break a report someone uses” (Incorrect): Keeping unknown tags costs speed and may break consent rules.
  • “Add a 39th tag that measures how long the other tags take to load” (Incorrect): Another tag adds cost without deciding anything.
  • “Move all 38 tags to async and keep every one of them” (Incorrect): Async helps loading, but unknown tags still cost time and may break rules.
  • “List owners and purposes, and remove tags nobody owns or uses” is correct.

    A tag register makes each tag justify its cost.

    • Check: consent covers each remaining tag.
    • Then: review regularly.

📖 Revise: Lesson 3: Page weight, blocking scripts and third-party tags

Question ID sp-digital-marketing-03-q6 · Report a mistake in this question
7. A shop lazy-loads every image, including the main product photo at the top. What's the likely effect?

Why each option is right or wrong

  • “Faster pages everywhere, as lazy loading is safe for any image” (Incorrect): It isn't safe for the main image in view.
  • “Better CLS, since the photo no longer affects the layout at all” (Incorrect): Lazy loading doesn't remove the image from the layout.
  • “No effect, since browsers ignore lazy loading on product pages” (Incorrect): Browsers apply it to any image with the attribute.
  • “A later Largest Contentful Paint, as the main photo starts loading late” is correct.

    The browser waits before fetching the photo that's usually the LCP element.

    • Fix: load it normally.
    • Lazy-load: images further down.

📖 Revise: Lesson 4: Images, fonts and mobile-first pages

Question ID sp-digital-marketing-03-q7 · Report a mistake in this question
8. A product page shows full details on desktop but hides them on phones. What's the SEO risk?

Why each option is right or wrong

  • “None, because search engines index the desktop version of every page” (Incorrect): They mostly index the mobile version.
  • “Only that the desktop page loads more slowly than the phone page” (Incorrect): The bigger risk is missing content.
  • “The phone page will rank higher, since shorter pages rank better” (Incorrect): Length alone isn't a ranking factor.
  • “With mobile-first indexing, the hidden details may not count at all” is correct.

    Search engines mostly use the mobile version, so content missing there may be ignored.

    • Fix: the same content on every screen.
    • Also: better for phone shoppers.

📖 Revise: Lesson 4: Images, fonts and mobile-first pages

Question ID sp-digital-marketing-03-q8 · Report a mistake in this question
9. An audit lists 140 problems in random order and nothing gets fixed. What would help the team act?

Why each option is right or wrong

  • “Adding more problems, so the audit looks more thorough and complete to the client” (Incorrect): A longer list makes acting harder.
  • “Sending the same spreadsheet again with a reminder email attached” (Incorrect): The problem is the list, not the reminder.
  • “Fixing the easiest problems first, whatever their impact on search” (Incorrect): Impact matters as well as effort.
  • “Group them, rate severity and effort, and put critical problems first” is correct.

    Ordered, grouped issues show the team where to start.

    • Critical: blocked pages, wrong noindex.
    • Record: fix and status.

📖 Revise: Lesson 5: Running a technical SEO audit

Question ID sp-digital-marketing-03-q9 · Report a mistake in this question
10. Which issue in a technical audit is most severe?

Why each option is right or wrong

  • “Some product images have alt text that could be more descriptive” (Incorrect): Worth fixing, but pages are still found.
  • “Two meta descriptions are slightly longer than 160 characters each” (Incorrect): Low severity; they may be cut off on screen.
  • “One heading uses h3 where h2 would fit better in a section” (Incorrect): Small structural issue, low severity.
  • “A staging noindex left on the shop's best-selling product page” is correct.

    The page can't be listed at all, so it gets no organic visits.

    • Fix: remove the tag.
    • Check: every template before launch.

📖 Revise: Lesson 5: Running a technical SEO audit

Question ID sp-digital-marketing-03-q10 · Report a mistake in this question

ProLearners Assist