How Core Web Vitals drive enrollments away from your site

There is a kind of loss no media report shows. The ad worked, the click happened, the budget was charged, and the applicant still never reached the form, because the page took longer than their patience.

Core Web Vitals are Google's attempt to measure exactly that interval. They do not assess the server or the code, they assess what the person perceives between clicking the link and being able to use the page.

For an educational institution, that difference is expensive. The most valuable traffic of the year arrives precisely at the application peak, when the site takes the most simultaneous visits and usually responds worst.

What are Core Web Vitals and why does Google use them?

Core Web Vitals are three page experience metrics defined by Google: LCP, which measures how long the largest visible element takes to appear; INP, which measures the delay between a user interaction and the screen's response; and CLS, which measures how much content jumps around during loading.

The choice of those three is not arbitrary. They cover the three most common complaints from anyone using a site on a phone: slow to see, slow to respond, and a button that moves right as you tap it.

Caption: Core Web Vitals measure the gap between the click and the application, and it is in that gap that the enrollment is lost

Google publishes the thresholds it considers good in the official Core Web Vitals documentation: LCP at up to 2.5 seconds, INP below 200 milliseconds and CLS below 0.1.

Those numbers apply to the 75th percentile of real visits, measured over a 28-day window according to the Core Web Vitals report in Search Console. The site has to deliver that experience to three out of four people, not only to whoever opens the page on a laptop with fiber.

On the ranking weight, Google is measured in its own documentation. The page Understanding page experience in Google Search results states that core ranking systems aim to reward content with a good experience, and that there is no single signal. The effect is a tiebreaker.

Treating the metric as the goal leads somewhere wrong. A site with an excellent score and incomplete information keeps losing applicants, because speed solves friction, not doubt.

How does a slow site kill student recruitment?

A slow site kills student recruitment at three specific points: on arrival from an ad, on the program page and in the application form. At all three the loss is silent, because an applicant who gives up produces no error, no contact and nothing in any campaign report.

Arrival from an ad is the most expensive of the three. The institution paid for the click, and the abandonment happens before any content loads, which turns media budget into nothing measurable.

The program page loses in a different way. It is almost always the heaviest page on the site, with a large banner, an institutional video and a gallery, and it is precisely the page the applicant opens on a work break, on an unstable connection.

The form suffers from INP and CLS. A field that lags on tap and a button that shifts position mid-entry produce abandonment at the final step, after all the effort of attraction.

The aggravating factor is the device. TIC Domicílios 2024, from CGI.br, puts mobile at 99% of internet access in Brazil, with 60% of users connected only that way. web.dev notes that performance varies with device capability and with the network.

Video: the mobile experience that Core Web Vitals measure, on the mkt4edu channel (in Portuguese)

When the analysis separates performance by page, the conversation with the technology team changes. It stops being “the site is slow” and becomes “the Nursing program page has a 5-second LCP on mobile, and it receives 30% of our budget”.

There is also a reputational effect on top of the conversion one. An institution that delivers a sluggish experience on a program page signals carelessness before any argument about academic quality.

How do you measure LCP, INP and CLS on your institution's site?

Measuring Core Web Vitals uses two sources that answer different questions: field data, collected from real visits and available in PageSpeed Insights and the Search Console report, and lab data, simulated by Lighthouse. The prioritization decision comes from the field; the diagnosis of the cause comes from the lab.

That distinction avoids a frequent, unproductive argument. The technology team shows a high lab score, marketing insists the site is slow, and both are right, because they are looking at different measurements.

The Search Console report is the best starting point for anyone managing a large site. It groups URLs with the same problem, which reveals template patterns rather than isolated pages.

PageSpeed Insights is for individual analysis. It shows the field data for that URL, when there is enough volume, and lists the corresponding technical opportunities.

Always measure under two conditions: mobile and desktop, separately. Averaging the two hides the problem, because mobile almost always drags the result down and mobile is where the applicant is.

Here is what each metric measures and where the impact shows up in recruitment:

Table: Thresholds published by Google and the practical effect of each metric on the application funnel.

Crawling also enters this equation, though by another route. Heavy pages consume more crawl resources, and how Google's crawler behaves explains why large institutional sites are slow to reflect recent changes.

What to fix first: homepage, program page or form?

The order of correction follows the money, not the score. First come the pages that receive paid media, then the program pages with the most organic search, then the application form, and only then the homepage, which usually has the worst score and the least real weight in conversion.

The homepage misleads because it is the page most often shown in a board report. It receives brand traffic, from people who already decided to look up the institution, and that visitor tolerates more lag than the applicant arriving from an ad.

Campaign landing pages have an immediate effect. Fixing the load time of a landing page that receives daily budget changes cost per lead within the same cycle.

The program page comes next, because it attracts the most high-intent search. It concentrates the queries by program name, which are the closest to the enrollment decision.

The form closes the priority list. Tracking scripts, real-time validation and third-party widgets tend to be the main cause of poor INP, and well-built lead capture forms reduce that friction without losing useful information.

Video: how to turn a site analysis into a fix list, Core Web Vitals included, on the mkt4edu channel (in Portuguese)

Three corrections resolve most cases on institutional sites: compress and size images, reserve fixed space for banners and ads, and defer scripts that are not part of the first screen. None of them requires rebuilding the site.

The gain tends to be lost when there is no publishing rule. With no criteria for image and script weight, the site returns to its previous state within months, at the pace new campaigns go live.

What do Core Web Vitals change in SEO strategy and in AI search?

Core Web Vitals support SEO strategy, but they do not replace content or authority. They work as a technical foundation: a fast, stable page has a better chance of being crawled, indexed and chosen in a tiebreaker, which matters when several institutions compete for the same query.

The relationship with AI search is more direct than it looks. Google states in its documentation on AI features in Search that there are no additional requirements to appear in those features, and that the page has to be indexed and snippet-eligible.

The practical consequence is simple. What secures presence in AI-generated answers is the same thing that secures presence in traditional search, and performance belongs to that package as hygiene, not as a shortcut.

There is a technical detail that often escapes marketing teams. Information that only appears after JavaScript runs tends to be less reliable for automated extraction, so a heavy page exposes less of its own content.

Among an institution's SEO strategies, speed is the one that makes the least impressive presentation and unlocks the most. Excellent content on a slow page returns less than reasonable content on a stable one.

That is also why SEO work needs access to the technology team early in the project. Much of the diagnosis depends on template and infrastructure decisions that no amount of copy optimization reaches.

Anyone working with zero-click search and direct answers in the SERP knows the side effect of that new layer: when the click does happen, it is worth more, and landing on a slow page wastes a visit that is getting rarer.

How do you track Core Web Vitals after the fix?

Tracking after the fix needs three routines: a monthly review of the page experience report in Search Console, spot checks on the pages that receive budget, and a publishing rule that prevents regression. Without the third, the first two become a log of decline.

Patience is part of the method. The Core Web Vitals report in Search Console works on the last 28 days, so a fix published today only shows up consolidated weeks later, which usually causes unnecessary anxiety.

The indicator marketing cares about is not the score. It is the conversion rate of the fixed page before and after, compared against the same period of the previous cycle to neutralize seasonality.

It is also worth tracking the commercial effect. Contact volume per page, time to first response and application rate are the numbers that connect technical performance to student recruitment and retention on a single dashboard.

Retention enters this equation by a less obvious route. A slow student portal and virtual learning environment raise friction for people already enrolled, and that friction weighs most in the first weeks of a course, which are the most critical.

Educational consulting that works on performance tends to include this measurement in the same recruitment report, rather than leaving it on a separate technical dashboard nobody in marketing opens.

The argument for keeping that tracking is cost. Performance is one of the few adjustments that benefits recruitment and retention at the same time, without requiring new media budget each cycle.

Common questions about Core Web Vitals

Where should you start fixing Core Web Vitals?

Start with the ten pages that receive the most budget and search. Measuring the whole site produces a list too long to prioritize, while measuring what already receives qualified traffic turns a technical metric into a recruitment decision.

Then separate what is a template problem from what is a page problem. Template fixes pay off at scale, because they reach hundreds of program URLs at once.

Finally, put the conversion number next to the technical number in the same report. That proximity is what makes performance stop being a technology topic and become part of the institution's Educational marketing strategy.

With performance fixed, the page still has to hold what the applicant came for. The article on best practices for getting a blog post to show up on Google closes the other side of that equation, which is the content of the page itself.