Website speed and Core Web Vitals

Google counts a page as good when the main content shows within 2.5 seconds (LCP), the page responds to a tap within 200 milliseconds (INP), and the page barely jumps around while it loads (a layout shift score, CLS, of 0.1 or less). A page passes when at least 3 out of 4 real visits meet those marks, so a good lab score isn't enough. If yours can't hit them, there's a fixable reason.

Speed alone won't push weak content up the rankings. But slow pages lose visitors before they read anything, and Google does factor page experience in.

Probably, if your content changes a few times a day or less and every visitor sees the same page. Pages built ahead of time (static generation) are the quickest to serve. If content changes often, pages can rebuild on a schedule or the moment an editor publishes (incremental static regeneration). If each visitor sees something different, like an account page, the server builds the page on each request (server rendering). I make this call while we scope the project.

Yes. The audit works on the site you have, whoever built it, and nothing gets rebuilt unless the ranked list says it's worth it.

It changes it. When an editor publishes, the CMS tells the site which pages to rebuild (a publish webhook), and those pages update on their own, with no developer involved. Storyblok, Sanity and Contentful all work this way.