Lecture 13: Speed, Mobile, Security, and Core Web Vitals

Short answer: Page speed, mobile usability, HTTPS security, and Core Web Vitals are the four pillars of Google's Page Experience signals. These are confirmed ranking factors that influence where pages rank independently of their content quality. This lecture covers what each factor measures, what the target thresholds are, how to diagnose your current performance, and how to fix specific issues identified in Google Search Console and PageSpeed Insights.

What You'll Learn in This Lecture

• What Google's Page Experience Signals Are and How They Rank Pages
• Core Web Vitals: LCP, INP, and CLS Explained in Depth
• How to Diagnose Core Web Vitals Issues in Google Search Console
• How to Fix LCP (Largest Contentful Paint) Problems
• How to Fix INP (Interaction to Next Paint) Problems
• How to Fix CLS (Cumulative Layout Shift) Problems
• Mobile Usability: What It Is and How to Pass Google's Mobile Test
• HTTPS: Security Requirements for 2026 SEO
• How to Monitor Page Experience Metrics on an Ongoing Basis

What Google's Page Experience Signals Are and How They Rank Pages

Google's Page Experience update, fully rolled out in 2021 and updated continuously since, introduced a set of signals that measure the quality of user interaction with a web page beyond just the content. The four current signals in the Page Experience system are: Core Web Vitals (LCP, INP, CLS), mobile usability (whether the page is usable on mobile devices), HTTPS (whether the site uses secure connection), and safe browsing (whether the page contains malware, deceptive content, or harmful downloads).

These signals function as a tiebreaker at the margin. Google has stated that Page Experience signals are one of many factors in the ranking algorithm and that a page with "great content" will still rank even with poor page experience, against pages with equally great content and better page experience. In practice, in highly competitive search results where many pages have comparable content quality, page experience signals can be the differentiating factor that determines which page ranks in position 1 vs. position 4.

The current Page Experience signals are visible in Google Search Console under the "Experience" section: the Core Web Vitals report, the Mobile Usability report, and the HTTPS report each show the status of every eligible page on the site. Any page in the "Poor" category for any signal has a confirmed opportunity for improvement that may directly improve its ranking position.

Example: 2 financial services websites compete for the keyword "low interest personal loans." Both have comprehensive, well-written content covering loan types, eligibility requirements, and comparison of lenders. Site A has a Core Web Vitals score of "Good" on all 3 metrics for all pages. Site B has an LCP average of 5.2 seconds on mobile, placing 60% of its pages in the "Poor" category. In Google's algorithm, both sites have comparable content quality scores. Site A's Page Experience advantage contributes to it ranking position 2 vs. Site B's position 7 for the primary keyword, even though a manual content review would not clearly identify Site A's article as superior. When Site B improves their LCP to 2.1 seconds (moving into "Good" territory), they rise from position 7 to position 3 over the following 6 weeks, with no content changes.

Core Web Vitals: LCP, INP, and CLS Explained in Depth

Core Web Vitals are a specific set of metrics that Google uses to measure real-world page experience. They are "field data" metrics -- measured from actual Chrome users visiting actual pages -- not laboratory simulations. There are currently 3 Core Web Vitals metrics.

Largest Contentful Paint (LCP) measures loading performance: specifically, how long it takes for the largest visible content element above the fold to fully render. This is usually a hero image, a large featured image, or a large block of text. The LCP element is identified by Chrome as whichever image or text block is the largest visible element during the load sequence. Good: under 2.5 seconds. Needs Improvement: 2.5 to 4.0 seconds. Poor: over 4.0 seconds. LCP is the Core Web Vital that most sites fail, primarily because of unoptimized hero images.

Interaction to Next Paint (INP) measures interactivity: how quickly the page responds to user interactions like clicks, taps, and keyboard inputs. INP replaced First Input Delay (FID) in March 2024. Unlike FID (which measured only the first interaction), INP measures the slowest interaction during the entire visit. Good: under 200 milliseconds. Needs Improvement: 200 to 500 milliseconds. Poor: over 500 milliseconds. INP is primarily affected by heavy JavaScript execution that blocks the main thread.

Cumulative Layout Shift (CLS) measures visual stability: how much the page layout unexpectedly shifts during loading. When a page's layout shifts, elements that users are interacting with move, causing accidental clicks and disorientation. The CLS score is the sum of all unexpected layout shift events during the page load. Good: under 0.1. Needs Improvement: 0.1 to 0.25. Poor: over 0.25. The most common causes of CLS are images without declared dimensions, late-loading ads that push content down, and web fonts that cause text reflowing when they load.

How to Diagnose Core Web Vitals Issues in Google Search Console

The Core Web Vitals report in Google Search Console (under "Experience" in the left navigation) shows field data from Chrome users who visited your site over a 28-day rolling window. It groups URLs by similarity and reports the Core Web Vitals status for each group as "Good," "Needs Improvement," or "Poor."

The GSC Core Web Vitals report is the primary diagnosis tool because it uses real user data (the Chrome User Experience Report, or CrUX). However, it requires sufficient traffic to generate reliable data. Pages with very low traffic may not appear in the GSC Core Web Vitals report due to insufficient data volume. For low-traffic pages, use PageSpeed Insights (pagespeed.web.dev) which provides lab data simulation instead of field data.

When the GSC report shows pages in the "Poor" category for LCP: click into the LCP issue group to see the specific URLs affected and the metrics. Then open those URLs in PageSpeed Insights to get the lab diagnosis: PageSpeed Insights identifies the specific LCP element (which image or text block), the estimated delay from each contributing factor (server response time, render-blocking resources, resource load delay, resource load time, element render delay), and specific recommendations for reducing LCP with estimated savings for each fix.

Example: A news website in Seattle, Washington has 40% of mobile pages in the "Poor" LCP category in GSC. Opening their most-trafficked article in PageSpeed Insights reveals: LCP element is the article hero image, current LCP is 4.8 seconds. Breakdown of delay: 0.3s TTFB (server response), 1.4s render-blocking resources (3 JavaScript files blocking page render), 2.1s resource load time (the hero image itself is 2.8MB JPEG), 1.0s element render delay. The diagnosis points to 2 actionable fixes: eliminate render-blocking JavaScript (saves estimated 1.4s) and compress/convert the hero image to WebP (saves estimated 1.6s). After implementing both fixes, LCP drops from 4.8s to 2.0s. The GSC Core Web Vitals report moves the article URL group from "Poor" to "Good" within 28 days of real user data accumulating after the fix.

How to Fix LCP (Largest Contentful Paint) Problems

LCP is the Core Web Vital most commonly in the "Poor" range for most websites, and it is also the one most responsive to concrete technical fixes. The 5 most impactful LCP fixes:

Fix 1: Optimize the LCP image. Convert to WebP or AVIF format (25 to 50% smaller than JPEG at equivalent quality). Resize to the actual display size (a 4,000px wide image loaded for a 800px wide display is 25x more data than necessary). Compress to the lowest acceptable quality level (usually 80 to 85% quality for WebP is visually indistinguishable from 100%). Target: under 150KB for a typical hero image. This single fix produces the largest LCP improvement on most sites.

Fix 2: Preload the LCP resource. Add a <link rel="preload" as="image"> tag in the HTML head for the LCP image. This instructs the browser to begin fetching the LCP image immediately when the page starts loading, instead of waiting for the browser to parse the HTML and discover the image later in the load sequence. Preloading the LCP image typically saves 0.3 to 0.8 seconds of LCP delay.

Fix 3: Eliminate render-blocking resources. JavaScript and CSS files that are loaded in the document head block HTML parsing until they are downloaded and executed. Add defer or async attributes to non-critical JavaScript tags. Move non-critical CSS to load after the above-the-fold content renders (or inline critical CSS in the HTML head). This reduces the time before the browser can begin rendering the LCP element.

Fix 4: Improve server response time (TTFB). Add a CDN to serve static assets from servers closer to the user. Enable server-side caching (e.g., page caching for CMS sites). Upgrade to faster hosting if current TTFB is over 600ms. A slow TTFB adds directly to LCP because the browser cannot start loading any resources until the server responds.

Fix 5: Avoid lazy-loading the LCP element. Lazy loading (loading="lazy") delays image loading until the image is about to enter the viewport. For most images below the fold, lazy loading is correct and improves performance. But if the LCP image is above the fold, lazy loading it delays its rendering unnecessarily. The LCP image (and only the LCP image) should have loading="eager" (or no loading attribute, since eager is the default).

Example: An e-commerce furniture store in Los Angeles, California has a category page LCP of 5.6 seconds on mobile. Investigation reveals: the category hero banner image is a 3.8MB PNG file, a render-blocking Google Tag Manager script is loaded synchronously in the head, and the hero image has a loading="lazy" attribute (incorrect for an LCP element). After: converting the image to WebP (reduces to 180KB), adding a preload tag for the hero image, moving GTM to load with the defer attribute, and removing the lazy-loading from the hero image, LCP improves from 5.6s to 1.9s. This moves the category page from "Poor" to "Good" for LCP. Google's ranking signals recognize the improvement within 28 days as field data from real users updates the CrUX database, and the category page rises 4 positions for its primary category keyword.

How to Fix INP (Interaction to Next Paint) Problems

INP problems are caused by main-thread blocking: JavaScript tasks that take too long to execute prevent the browser from responding to user interactions (clicks, taps, key presses) promptly. When a user clicks a button while a long JavaScript task is running, the browser cannot register the click until the current task finishes. If the task takes 500ms, the user experiences a 500ms delay before anything happens, producing a poor INP score.

The primary causes of poor INP and their fixes: Long JavaScript tasks from third-party scripts (ads, analytics, chat widgets, social sharing buttons). Each third-party script added to a page potentially adds JavaScript execution time that blocks the main thread. Fix: audit all third-party scripts with Chrome DevTools Performance tab. Remove any that are not delivering measurable business value. Load remaining third-party scripts with defer or async to prevent them from blocking the initial render. For widgets like chat tools, load them only after user interaction (lazy-load on first mouse movement).

JavaScript framework hydration (React, Vue, Angular, Next.js): When a JavaScript-heavy page loads, the framework must "hydrate" the static HTML (attach event listeners and make it interactive). This hydration process can take 2 to 8 seconds on slower devices, during which time user interactions are queued and delayed. Fix: reduce JavaScript bundle size (code splitting, tree shaking), implement partial hydration (hydrating only interactive components, not the entire page), and defer hydration of below-the-fold components until they are needed.

Long event handlers: Individual JavaScript functions tied to user interactions (click handlers, form submission handlers) that take more than 50ms to execute will cause INP delays. Fix: profile event handlers with Chrome DevTools, break long synchronous tasks into smaller asynchronous chunks using requestAnimationFrame or setTimeout, and defer any work that does not need to happen immediately in response to the user's action.

Example: A media streaming service in New York, New York has a "Poor" INP score on their video player pages. Chrome DevTools Performance analysis reveals: a Google Ads script loads and executes 1.4 seconds of main-thread blocking code 500ms after page load. During those 1.4 seconds, any user clicks (on play buttons, quality settings, or volume controls) are queued and execute only after the ads script finishes. After moving the Google Ads script to load with the async attribute and adding it via script injection after the page load event fires, the ads script no longer blocks the main thread during initial page load. INP on video player pages drops from 780ms (Poor) to 110ms (Good). The improvement is noticeable to users as button clicks on the video player now respond instantly. GSC INP field data updates within 28 days, and the "Poor" INP classification on all affected pages resolves to "Good."

How to Fix CLS (Cumulative Layout Shift) Problems

Cumulative Layout Shift is the Core Web Vital most directly noticed by users, because a layout shift is a visible, disruptive event: content jumps, buttons move, users accidentally click the wrong element. CLS is caused by content that loads after the initial page render and takes up space that other content then has to move around to accommodate.

The 4 most common CLS causes and fixes: Images without declared dimensions (fix: always add explicit width and height attributes to all img tags so the browser reserves the correct space before the image loads). Ads without reserved space (fix: reserve a minimum space for ad units by setting a min-height on the ad container before the ad loads, so the ad slot space is pre-allocated and content does not shift when the ad appears). Web fonts causing FOUT or FOIT (Flash of Unstyled Text / Flash of Invisible Text: fix: use font-display: optional or font-display: swap carefully, and preload key fonts so they are available before the first render). Dynamic content injected above existing content (fix: do not add new content above existing visible content unless responding to a user interaction; content added above existing content always causes a CLS event for the displaced content below).

To identify which specific elements are causing CLS on a page, use the Chrome DevTools "Rendering" panel with the "Layout Shift Regions" feature enabled: it highlights in blue any elements that shift during the page load, making it immediately obvious which content is moving and approximately when during the load sequence it is moving.

Example: A news website in Chicago, Illinois has a CLS score of 0.38 on article pages (Poor). Chrome DevTools Layout Shift Regions analysis shows: 3 elements are shifting. A banner ad slot that loads 1.2 seconds after the page renders and pushes the article text down by 90 pixels (the largest CLS contributor). The article hero image shifts slightly because it has no declared height attribute. A "recommended articles" widget loads 2 seconds after page load and inserts itself above the comments section. Fixes: add a min-height of 250px to the ad container (reserves the space before the ad loads), add explicit width and height attributes to all article images, and move the recommended articles widget below the comments section (or load it with position:absolute to prevent it from pushing other content). After fixes, CLS drops from 0.38 to 0.06 (Good). Users no longer accidentally click the ad slot when trying to click "Continue Reading" (the most common mis-click that the old layout shift was causing).

Mobile Usability: What It Is and How to Pass Google's Mobile Test

Mobile usability refers to whether a web page is accessible and usable on mobile devices: smartphones and tablets. As of 2023, Google uses mobile-first indexing for all new websites, meaning Google primarily uses the mobile version of a page for indexing and ranking. A page that works perfectly on desktop but is broken, cramped, or unreadable on mobile is at a significant SEO disadvantage.

The Mobile Usability report in Google Search Console identifies specific issues on pages that fail Google's mobile usability tests. The most common mobile usability errors are: "Text too small to read" (text that requires zooming to read on a mobile screen, caused by a font size below 12px), "Clickable elements too close together" (buttons, links, or interactive elements that are too small or too closely spaced for reliable finger tapping on a touchscreen), "Content wider than screen" (content that extends beyond the viewport width and requires horizontal scrolling), and "Viewport not set" (the page does not have a viewport meta tag, causing it to render at desktop width on a mobile device and appear zoomed out).

Fixing mobile usability issues: ensure the HTML head contains <meta name="viewport" content="width=device-width, initial-scale=1">. Use a responsive CSS framework or responsive CSS (using percentage widths, flexbox, or CSS grid) so content reflows for different screen sizes. Set minimum font size of 16px for body text (the default readable size for mobile without zooming). Ensure all interactive elements (buttons, links, form fields) are at least 44x44 pixels in tap target size with at least 8px of space between them. Test the site regularly in Chrome DevTools' mobile emulation view or on actual mobile devices.

Example: A dental practice in Phoenix, Arizona has 12 pages flagged in the GSC Mobile Usability report for "Clickable elements too close together." Investigation shows: their appointment booking buttons (Book Now, Call Us, Directions) are placed in a compact footer widget on mobile that groups all 3 buttons with only 2px of spacing between them. On a typical 6-inch smartphone screen, the buttons are 36px tall and 2px apart, making it near-impossible to tap the correct button without hitting an adjacent one. After redesigning the mobile footer to stack the 3 buttons vertically with 16px spacing each, button tap targets expanded to 48px height with 16px gaps. The Mobile Usability errors in GSC clear within 10 days as Googlebot recrawls the updated pages. The booking form completion rate on mobile increases 23% as users can now reliably tap the "Book Now" button without accidentally hitting "Call Us."

HTTPS: Security Requirements for 2026 SEO

HTTPS (covered in Lecture 3 as part of the website foundation setup) is the encryption standard that protects data transmitted between a user's browser and a web server. Google has confirmed HTTPS as a ranking signal since 2014, and in 2026 it is effectively a baseline requirement: any site without HTTPS is marked "Not Secure" by major browsers, faces a confirmed ranking disadvantage against HTTPS competitors, and will have difficulty building user trust needed for conversions.

The HTTPS section of Google Search Console (under "Experience") shows whether all indexed pages on the site are served over HTTPS. Common HTTPS issues: mixed content (the main page is HTTPS but some elements like images, scripts, or stylesheets are loaded over HTTP), expired SSL certificate (causes browser security warnings that send most users away immediately), and HTTP to HTTPS redirects not fully implemented (some pages still accessible over HTTP without redirecting).

For businesses operating in regulated industries (healthcare, finance, legal), HTTPS is legally required in addition to being an SEO requirement. Health information sites that collect any patient data, financial sites that handle payment information, and legal sites that manage client documents each have regulatory mandates that require encrypted connections under HIPAA, PCI-DSS, and similar frameworks. An expired or misconfigured SSL certificate on these sites is simultaneously an SEO problem, a regulatory problem, and a user trust problem.

Example: A telemedicine company in San Francisco, California discovers through GSC that 340 of their article pages are showing HTTPS errors. Investigation reveals: their blog content management system automatically includes images served from an old HTTP CDN bucket that was never migrated to HTTPS when the main site migrated in 2022. Every article page that includes one of these images shows a mixed content warning in Chrome and a partial "Not Secure" indicator in the browser address bar. The fix: migrate all 2,400 blog images from the HTTP CDN bucket to the HTTPS CDN endpoint and update all image URLs in the CMS. The migration takes 3 days. Within 2 weeks of the fix, GSC's HTTPS report clears all 340 errors. Bounce rate on article pages, which had been elevated by an estimated 15% due to the security warnings causing user abandonment, returns to baseline.

How to Monitor Page Experience Metrics on an Ongoing Basis

Page experience metrics change over time as content changes, new code is deployed, third-party scripts are added or updated, and server infrastructure changes. A site that has "Good" Core Web Vitals today can regress to "Poor" after a developer adds a new analytics script or a content team uploads uncompressed images. Ongoing monitoring is essential to catch regressions before they affect rankings.

The monitoring stack for page experience: Google Search Console Core Web Vitals report (checked monthly), PageSpeed Insights for the top 10 pages by organic traffic (run quarterly or after significant code deployments), Lighthouse CI or web-vitals library integrated into the development build pipeline (flags performance regressions during development before they reach production), and UptimeRobot or Pingdom for server uptime monitoring. For enterprise sites, web performance monitoring platforms like SpeedCurve or Calibre provide continuous synthetic monitoring with alerts when any metric crosses a threshold.

Establishing performance budgets is a proactive monitoring approach: define the maximum acceptable values for LCP, INP, CLS, and other performance metrics, and configure the monitoring system to alert when any page crosses those thresholds. Performance budgets are particularly effective when integrated into CI/CD (continuous integration/deployment) pipelines: any code change that would push a key page above the performance budget is flagged before it can be merged, preventing performance regressions from reaching production.

Example: A B2B marketing platform in Boston, Massachusetts integrates Lighthouse CI into their GitHub Actions CI/CD pipeline. Every pull request is automatically tested against performance budgets: LCP must be under 2.5s, CLS must be under 0.1, and Total Blocking Time (a proxy for INP in lab testing) must be under 300ms. In Q3, a developer submits a pull request that adds a new customer testimonial carousel with 8 full-resolution images and a JavaScript animation library. Lighthouse CI flags the PR: LCP increases from 2.1s to 4.2s (exceeds budget), TBT increases from 180ms to 520ms (exceeds budget). The PR is returned to the developer for optimization before merging. After optimizing the images to WebP format and replacing the heavy animation library with a lightweight CSS animation, the PR clears the performance budgets and is merged. The production site never experiences the performance regression because it was caught in the development pipeline before deployment.

Common Mistakes to Avoid

• Lazy-loading the LCP image (the above-the-fold hero image), which delays the loading of the single element most critical to the LCP score.
• Adding third-party scripts (analytics, ads, chat widgets) without auditing their main thread impact, progressively degrading INP scores over time.
• Publishing images without declared width and height attributes, causing layout shifts (CLS) every time images are added to the site.
• Implementing HTTPS but leaving mixed content errors (HTTP resources loaded on HTTPS pages), creating security warnings that reduce user trust and signal incomplete migration to search engines.
• Treating Core Web Vitals as a one-time project rather than setting up monitoring, allowing regressions after code deployments to go undetected until they affect rankings.
• Optimizing Core Web Vitals only for desktop users when Google's Page Experience signals are primarily evaluated on mobile (mobile-first indexing).

Action Checklist

• Check the Core Web Vitals report in GSC: identify all page groups in the "Poor" category for LCP, INP, and CLS.
• Run PageSpeed Insights on your top 5 pages by organic traffic. Note the LCP element, current LCP time, and specific recommendations for each page.
• For each image on the top 5 pages: verify WebP format, explicit width/height attributes, loading="lazy" only on below-the-fold images, and file size under 200KB.
• Check the Mobile Usability report in GSC for any flagged issues. Test the site in Chrome DevTools' mobile emulation at common screen sizes (375px and 390px width).
• Verify the HTTPS report in GSC shows no errors. Check for mixed content using Chrome DevTools Console on key pages.
• Run a third-party script audit: list all scripts loaded on your homepage, identify any that are not delivering clear business value, and evaluate removing or deferring each.

Practice Task

Run PageSpeed Insights on your homepage and your most important content page. Record the results in this table and prioritize fixes by estimated LCP impact.

Metric	Homepage (Mobile)	Key Content Page (Mobile)	Target	Top Fix to Apply
LCP (seconds)	Enter current value	Enter current value	Under 2.5s	Compress hero image to WebP
INP (milliseconds)	Enter current value	Enter current value	Under 200ms	Defer third-party scripts
CLS (score)	Enter current value	Enter current value	Under 0.1	Add width/height to images
TTFB (seconds)	Enter current value	Enter current value	Under 0.8s	Enable CDN / caching
LCP element identified	Hero image / Text block / Other	Hero image / Text block / Other	N/A	Preload LCP element

Related Lessons Across SEO, AEO, GEO, SEM, and PPC

Use these connected lessons to move through organic search, answer engines, generative AI visibility, paid search, and PPC without losing the bigger strategy.

• Lecture 1: SEO Fundamentals for Beginners (SEO) - return to the course foundation when you need the big picture.
• Lecture - 7: How AI Chatbots (ChatGPT, Gemini, Perplexity) Answer Questions (AEO) - understand how answer systems choose sources.
• Lecture - 4: How to Write Content That AI Systems Can Retrieve, Summarize, and Trust (GEO) - make content easier for AI systems to retrieve.
• Lecture 25: AI and Automation in SEM: Smart Bidding, AI Overviews, and the Future (SEM) - see how automation changes paid search.
• Lecture - 1: What Is AEO? How Answer Engines Are Different From Search Engines (AEO) - see how answer engines build on SEO foundations.

Course Links

• Back to Lecture 12: Site Architecture and Internal Linking
• Continue to Lecture 14: Structured Data and Rich Results
• Run a Free SEO Audit on Your Site

Trusted References

For Core Web Vitals thresholds and measurement methodology, see web.dev/vitals. For LCP optimization, see Optimize Largest Contentful Paint. For CLS optimization, see Optimize Cumulative Layout Shift. For mobile usability requirements, see Google's Mobile-First Indexing Guide.

FAQs

Do Core Web Vitals Affect Desktop and Mobile Rankings Separately?

Yes. Google evaluates Core Web Vitals separately for desktop and mobile and uses them as separate ranking signals for desktop and mobile search results. Because Google uses mobile-first indexing (the mobile version of a page is the primary version Google indexes and ranks), mobile Core Web Vitals are more impactful on overall rankings. However, a page with poor desktop Core Web Vitals may rank lower in desktop search results for users searching on desktop. Optimize for mobile first (as it affects the larger user base and the mobile-first index), then verify desktop scores are also in the "Good" range.

How Long After Fixing Core Web Vitals Issues Do Rankings Improve?

Core Web Vitals field data in GSC is based on a rolling 28-day window of Chrome User Experience Report data. After fixing an issue, the improvement in field data appears gradually over 28 days as new, better-performing visits replace old, poor-performing visits in the rolling window. The ranking impact, if any, typically follows within 4 to 8 weeks of the field data moving from "Poor" to "Good." This means the full ranking benefit of a Core Web Vitals fix may take 2 to 3 months from implementation to full ranking expression.

Should HTTPS SSL Certificates Be Renewed Every Year?

Standard SSL certificates (including free Let's Encrypt certificates) expire after 90 days to 1 year depending on the certificate type. Let's Encrypt certificates expire every 90 days but can be set up to auto-renew automatically through most hosting control panels. Most hosting providers handle auto-renewal of SSL certificates, but it is worth setting up monitoring to alert you if a certificate is approaching expiration. An expired SSL certificate immediately causes browser security warnings that block most users from accessing the site, creating both a user experience emergency and an SEO issue as Google may detect the certificate error during crawling.