#1 Fastest in the market. 21 day free trial.

Try Stellar A/B Testing for Free!

No credit card required. Start testing in minutes with our easy-to-use platform.

← Back to BlogMeasure First: Optimizing a Website in a 30/90/180-Day Plan

Measure First: Optimizing a Website in a 30/90/180-Day Plan

Strategist planning a website optimization timeline

Start by measuring with PageSpeed Insights and real user monitoring, then fix whatever is breaking your Core Web Vitals, and only after that run experiments to confirm your changes actually move the needle. That order matters more than any single tactic. This article walks through the diagnostics, the fixes, and a 30-, 90-, and 180-day plan you can run without a full engineering team.

TL;DR:

  • Fix the largest contentful paint by optimizing server response times, inlining critical CSS, and preloading only the necessary hero images.
  • Reduce JavaScript bundle size through code-splitting and limit third-party scripts, regularly auditing them to prevent main-thread slowdowns.
  • Use caching and a CDN to lower first contentful paint and ensure static assets load quickly for returning visitors.
  • Ensure URLs are descriptive, canonical tags are correctly set, and internal links highlight key pages to improve crawlability and ranking signals.
  • Measure Core Web Vitals with PageSpeed Insights and real user monitoring before and after fixes, and conduct controlled A/B tests to confirm actual performance improvements.

Table of Contents

Performance optimization: Core Web Vitals and speed fixes

Three metrics decide whether Google and your visitors think your site is fast: Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), and Interaction to Next Paint (INP). LCP measures how long the biggest visible element takes to render. CLS measures how much content jumps around while loading. INP measures how responsive the page feels when someone actually clicks or taps something. Good scores sit at LCP under a few seconds and CLS well below one tenth, with INP judged responsive at low milliseconds.

There are two very different ways to measure these numbers, and mixing them up leads to bad decisions. Field data, also called CrUX (Chrome User Experience Report), comes from real visitors over a rolling window and reflects what people actually experienced. Lab data comes from a single simulated run in a tool like Lighthouse and is useful for diagnosis but not for judging real-world performance. PageSpeed Insights combines both: it pulls 28 days of field data from CrUX and evaluates Core Web Vitals at the 75th percentile, then runs a Lighthouse audit for the lab diagnostics that explain why the field numbers look the way they do.

Field and lab performance data comparison

To fix LCP, first find the actual element Lighthouse flags as largest, usually a hero image or a headline block. From there, work backward: reduce server response time (TTFB), inline the critical CSS needed for the first screen, and preload the hero image only when it is genuinely the first thing rendered. Preloading everything in sight tends to backfire and slow other resources down.

Image handling is often the single biggest lever available to non-developers. A few habits cover most of the win:

  • Serve responsive images using srcset and sizes so phones don't download desktop-sized files.
  • Convert hero and content images to modern formats like WebP or AVIF instead of JPEG or PNG.
  • Lazy-load anything below the fold, but never lazy-load the LCP image itself.
  • Set explicit width and height attributes on every image to prevent layout shift while they load.

Fonts cause two separate problems: they delay LCP if render-blocking, and they cause CLS if the fallback font renders at a different size than the custom one. Self-hosting fonts instead of pulling them from a third party removes a slow round trip, and choosing a deliberate font-display strategy, such as swap or optional, controls whether text appears immediately in a fallback font or waits for the custom one.

JavaScript weight is the quiet killer of INP. Large bundles keep the main thread busy, which delays how quickly a page responds to clicks. Code-splitting so pages load only the script they need, avoiding importing an entire library for one function, and setting a browserslist configuration so your build tool doesn't ship unnecessary legacy code for modern browsers all shrink that bundle meaningfully.

Third-party scripts, chat widgets, ad tags, and analytics snippets, deserve the same scrutiny. Measure what each one actually costs using the browser's Performance panel, then lazy-load or remove anything that isn't earning its keep. A related piece on lightweight website optimization goes deeper into why script weight compounds across a session.

Pro Tip: Audit third-party scripts quarterly. Marketing teams add tracking pixels faster than anyone removes them, and each one adds to the main-thread work that hurts INP.

Finally, caching and a content delivery network (CDN) reduce TTFB and repeated fetch times by serving static assets from servers physically closer to the visitor and skipping redundant origin requests. Set cache headers aggressively for assets that rarely change, images, fonts, compiled CSS and JS, so returning visitors barely wait at all.

PageSpeed Insights and Lighthouse remain the standard first stop for diagnosing all three Core Web Vitals, since they combine field and lab data in one report. For a full walkthrough of speed diagnostics beyond what fits here, see Breaking the 2-Second Rule.

Technical SEO and site structure: crawlability, URLs, and sitemaps

Search engines can only rank pages they can find, fetch, and understand, so the technical layer comes before any content polish. Check these fundamentals first:

  1. Confirm robots.txt isn't accidentally blocking sections you want indexed.
  2. Submit an updated XML sitemap through Google Search Console and keep it free of redirected or non-canonical URLs.
  3. Scan for stray noindex tags left over from staging environments or plugin defaults.
  4. Verify that important pages are reachable within a few clicks from the homepage, not buried five folders deep.

URL structure matters for both crawlers and humans. A descriptive path like /blog/website-speed-guide tells you and Google more than an auto-generated string of numbers, and grouping related content into consistent directories, /blog/, /guides/, /case-studies/, gives search engines a clearer sense of topical clusters on your site.

Duplicate or near-duplicate content confuses ranking signals, which is where canonical tags earn their keep: they tell search engines which version of a page is the one to index when several URLs show similar content, such as filtered product listings or printer-friendly pages. Sites serving multiple languages or regional variants add hreflang tags so the right version reaches the right audience, though this only applies once you actually have more than one language version live.

Internal linking is the cheapest way to tell search engines, and readers, what matters most on your site:

  • Link from high-traffic pages down to important pages that aren't getting enough visibility on their own.
  • Use descriptive anchor text instead of generic phrases like "click here."
  • Avoid orphan pages with zero internal links pointing to them.

Structured data helps search engines display richer results and understand page context. For most sites, three types cover the bulk of practical use: Article schema for blog content, FAQ schema for question-and-answer sections like the one at the end of this piece, and HowTo schema for step-by-step instructional content. Add these where they genuinely match the page's content rather than everywhere for the sake of it, since mismatched structured data can trigger manual review flags.

On-page content, relevance, and conversion optimization

Every page needs a clear job. Before writing a word, decide whether the page exists to inform, compare, or convert, and let that decision shape the structure. Keyword stuffing wastes effort that clear headings and a direct opening paragraph would spend better: search engines and readers both reward content that answers the query in the first few sentences, then expands with supporting detail.

Title tags and meta descriptions are your pitch in the search results, not just metadata. A title that states the topic plainly and a meta description that promises a specific answer both tend to earn more clicks than vague, keyword-packed versions. Header structure should mirror how a reader actually scans: one clear H1, then H2 sections that each answer a distinct sub-question.

Content depth still separates pages that rank from pages that don't, but depth means specificity, not length for its own sake. Supporting links to authoritative sources, visible author attribution, and concrete data all signal the kind of experience and trustworthiness search engines and readers both weigh.

Conversion optimization on the page itself often comes down to reducing friction rather than adding persuasion:

  • State the value proposition in the first screen, not buried after three paragraphs of context.
  • Use one primary call to action per page instead of competing buttons.
  • Cut form fields down to what you actually need for the first interaction.
  • Make the next step visually obvious, not just technically clickable.

Pro Tip: Before rewriting a page's copy, test one change at a time, headline, CTA text, or form length, so you know which change actually caused the lift.

Not every content or layout change needs a full experiment, but anything touching a high-traffic page or a conversion path is worth testing before a permanent rollout. A/B testing tells you whether a redesigned hero section actually increases sign-ups or just feels better in a meeting. Partner coverage on boosting SEO and conversions through faster site speed makes a similar case: technical and content work reinforce each other rather than competing for priority.

UX and accessibility: reduce friction and follow WCAG basics

Accessibility work and general usability overlap more than most teams expect. The Web Content Accessibility Guidelines (WCAG) 2.2 organize requirements around four principles: content must be perceivable, operable, understandable, and robust across assistive technologies. Meeting these criteria tends to improve the experience for every visitor, not just those using a screen reader or keyboard-only navigation.

Mobile layout deserves attention first, since most traffic arrives on a phone. Tap targets need enough spacing that a thumb doesn't miss, images need to resize gracefully across screen widths, and text needs to stay legible without pinch-zooming. Our guide to optimizing mobile landing pages covers the layout patterns that hold up best on small screens.

A practical WCAG checklist covers most common gaps:

  • Add descriptive alt text to every meaningful image, and empty alt attributes for purely decorative ones.
  • Maintain sufficient color contrast between text and background, especially for buttons and links.
  • Make every interactive element reachable and operable by keyboard alone.
  • Label form fields explicitly instead of relying on placeholder text as the only cue.
  • Provide visible controls for any auto-playing video or audio.

Layout stability ties directly back to accessibility and to CLS. Setting explicit dimensions on images and video embeds, and choosing a font loading strategy that avoids a visible swap, keeps the page from jumping while someone is trying to read or click.

The overlap with SEO and conversions is not a coincidence: semantic HTML structure and clear labeling help both screen readers and search engine crawlers parse a page correctly, which is one reason accessibility improvements often show up in engagement metrics as well as in compliance audits.

Measurement, testing, and iteration that actually prove impact

Every fix in this article needs a before-and-after number, or you're guessing. Here's a workable sequence:

  1. Run PageSpeed Insights on both mobile and desktop for your key pages, and read the field data (CrUX) and lab data (Lighthouse) as two separate signals, one reflecting real visitors, the other explaining root causes.
  2. Set up Real User Monitoring or use your existing analytics platform to track LCP, INP, and CLS by page template and device type, since a single site-wide average hides which pages are actually dragging the numbers down.
  3. Rank the fixes you find by impact versus effort, and tackle the high-impact, low-effort items first rather than the most technically interesting ones.
  4. Build a simple tracking dashboard so stakeholders see the trend line, not just a one-time score.

Our guide to website performance metrics breaks down which numbers matter to which audience, useful when you need to explain a CLS improvement to someone outside engineering.

A/B testing is where speed and content work get proven, not just guessed at. The core workflow is simple: form a hypothesis, set up the variant, run it long enough to reach a stable sample, then measure against your defined success metric before rolling it out permanently. The common failure points are ending a test too early, testing traffic too low to reach a reliable result, and misconfigured tracking that reports a false lift.

Pro Tip: Let a test run a full business cycle, generally at least one to two weeks, so weekday and weekend behavior both get represented before you call a winner.

Prioritized checklist: your 30/90/180-day plan

Spread the work so quick wins build momentum while bigger fixes get proper attention.

In the first 30 days:

  • Run PageSpeed Insights on your top pages and identify the single biggest LCP cause.
  • Remove or lazy-load nonessential third-party scripts.
  • Compress and resize hero images to the dimensions they're actually displayed at.

In the next 90 days:

  1. Put CDN and caching rules in place for static assets.
  2. Finalize a font loading strategy, self-hosted files with a deliberate font-display setting.
  3. Trim the critical CSS path so the first screen renders without waiting on unused styles.
  4. Reorganize key content and internal links around your highest-value pages.

By 180 days:

  • Refactor the heaviest JavaScript bundles with code-splitting.
  • Work through accessibility audit findings from the WCAG checklist above.
  • Have a running A/B testing pipeline rather than one-off tests.

Track the same handful of metrics throughout: LCP, INP, CLS, conversion rate, and bounce or engagement rate. Log every experiment with its hypothesis, duration, and result, even the ones that lose, since a documented failure saves the next person from repeating it.

Security best practices that also affect performance

HTTPS is no longer optional groundwork, it's baseline infrastructure that also touches performance. Modern HTTP/2 and HTTP/3 protocols, which unlock features like multiplexed requests and header compression, require HTTPS to function at all in most browsers. Sites still running plain HTTP lose both the trust signal and the protocol-level speed gains that come with a properly configured TLS certificate.

A Content Security Policy (CSP) restricts which scripts, styles, and resources are allowed to load on your page, which primarily protects against injected malicious code. Configured well, it also forces a useful discipline: you end up with an explicit inventory of every script your site actually loads, which tends to surface forgotten third-party tags that were quietly hurting your INP anyway.

Neither of these is a speed feature on its own, but both remove friction that otherwise slows a page down or blocks it from newer protocol benefits entirely. Set them up once, correctly, and they stay out of the way.

SEO beyond the page: backlinks and content relevance

On-page fixes only get you so far. Search engines also weigh how the rest of the web talks about your site, which is where backlinks come in: links from other relevant, reasonably trusted sites act as a vote of confidence, and a page with several relevant backlinks tends to outrank an otherwise identical page with none.

Earning them usually comes down to creating something worth citing, original data, a genuinely useful tool, or a guide detailed enough that other writers link to it instead of rewriting it. Guest contributions and partner content exchanges can help, but only when the content is genuinely relevant to both audiences rather than placed purely for the link.

Content relevance matters just as much as link count. A page that thoroughly answers the query it targets, and connects naturally to related topics on your own site through internal links, tends to hold rankings better over time than a page optimized narrowly around one keyword phrase. Search engines increasingly evaluate whether a whole site demonstrates depth on a topic, not just whether one page mentions the right words.

What most teams get wrong about optimization timelines

Most teams underestimate how much of this work is diagnostic, not technical. Finding the actual LCP element or the script actually blocking the main thread often takes longer than fixing it once you know. Budget for that discovery time instead of assuming every fix is a quick patch.

The real trade-off isn't speed versus features, it's speed versus how quickly you're willing to ship. Perfect accessibility compliance or a fully optimized bundle can wait; a broken checkout flow cannot. Treat this as a backlog, not a launch gate.

Measure before you change anything, and keep changes small enough to reverse if they don't help. A confident guess still costs you the two weeks it takes to find out you were wrong.

— Juan

Running experiments without slowing your site down

Every fix above earns you nothing until you know whether it actually moved a real metric, and that's the part most small teams skip because traditional testing tools add their own performance overhead. A lightweight script can help avoid canceling out the speed gains you just spent weeks earning.

Gostellar

A few things make it practical for teams without a dedicated developer:

  • A no-code visual editor can let teams build and launch tests without touching the codebase.
  • Dynamic keyword insertion can personalize landing pages for different traffic sources without duplicating pages.
  • Advanced goal tracking can connect test variants directly to the conversion events that matter.

If you're validating a headline change, a form redesign, or a new CTA placement, running it through a lightweight testing setup means you get a real answer instead of a guess dressed up as intuition. Check plans and get started, including a free tier for sites under 25,000 monthly tracked users.

Sources

FAQ

What are the 7 steps to building a good website?

There's no single official standard, but a practical build sequence covers planning and goals, information architecture, wireframes and design, content creation, development, testing across devices and browsers, and launch with ongoing measurement. Accessibility and speed checks belong in the testing stage, not as an afterthought once the site is live.

How do you optimize the performance of a web page?

Start by measuring the page with PageSpeed Insights to see both field and lab data, then address the biggest Core Web Vitals problem it flags, usually an oversized image, unoptimized fonts, or heavy JavaScript. Fix the highest-impact issue first, remeasure, and repeat rather than trying to fix everything in one pass.

How to optimize web content?

Write to match what the searcher actually wants from the page, answer it clearly in the opening lines, and structure the rest with headings that each cover one sub-question. Support claims with credible links, keep paragraphs scannable, and pair any content change on a high-traffic page with an A/B test before rolling it out permanently.

How often should I re-run PageSpeed Insights after making changes?

Re-run it immediately after any speed-related change to confirm the fix worked, then check monthly since Core Web Vitals field data reflects a rolling 28-day window rather than a single snapshot. Checking too soon after a change can show incomplete field data still catching up.

Do accessibility fixes actually help SEO?

Many accessibility improvements, like descriptive alt text and clean semantic structure, help search engines parse a page more accurately, which can support how it's indexed and understood. The WCAG 2.2 guidelines are written for usability and inclusivity first, but the overlap with crawlability is a genuine side benefit, not the primary goal.

Recommended

Published: 9/29/2026