How do you improve your Lighthouse performance score?

You improve your Lighthouse performance score by fixing what the report flags, most often by caching static assets, deferring and reducing JavaScript, and serving files efficiently. Lighthouse measures how fast your page loads and becomes interactive, then scores it and lists the specific issues holding you back. The score isn’t the goal in itself; it’s a proxy for real user experience, and the two biggest levers for most sites are caching and JavaScript optimisation.

Key Takeaways

• Lighthouse scores performance from metrics including LCP, Total Blocking Time, and CLS, the same signals behind Core Web Vitals.
• “Good” Core Web Vitals are LCP 2.5s or less, INP 200ms or less, and CLS 0.1 or less, at the 75th percentile (web.dev).
• Caching static assets with Cache-Control headers makes repeat visits dramatically faster.
• Deferring, lazy-loading, and minifying JavaScript cuts the blocking time that drags scores down.

A good Lighthouse score reflects a fast, stable page, which keeps visitors and helps SEO. This guide explains the metrics Lighthouse measures, then walks through the highest-impact fixes: caching, JavaScript optimisation, and serving assets well. It builds on our wider guide to improving Core Web Vitals.

What does Google Lighthouse measure?

Google Lighthouse measures your page across performance, accessibility, best practices, and SEO, giving each a score out of 100 and listing specific fixes. It’s free, built into Chrome DevTools (and available as a standalone tool), and it simulates a visit to your page to produce a detailed, actionable report.

The performance score is built from lab measurements of several metrics. The ones that matter most are Largest Contentful Paint (LCP), how long until the main content appears; Total Blocking Time (TBT), how long the main thread is blocked and unable to respond; and Cumulative Layout Shift (CLS), how much the page jumps around as it loads. First Contentful Paint and Speed Index round out the picture. These map closely to Core Web Vitals, Google’s real-user performance signals, where good means LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less at the 75th percentile (web.dev). One caveat worth knowing: Lighthouse runs a lab test on a single simulated load, so use it to diagnose and verify fixes, then confirm improvements in real-user field data over the following weeks.

How does caching improve performance?

Caching improves performance by storing copies of your static files, images, CSS, and JavaScript, so they don’t have to be downloaded again on every visit. For returning visitors, cached assets load almost instantly from their device instead of travelling across the network, which is one of the biggest speed wins available.

There are three layers worth using together. Browser caching stores assets on the visitor’s device, controlled by the headers you send. Server-side caching stores rendered pages or data so the server doesn’t rebuild them every request (WordPress caching plugins and Nginx/Apache caches do this). And a Content Delivery Network (CDN) stores your files on servers around the world, serving each visitor from the nearest one to cut latency. The control that matters most for browser caching is the Cache-Control header, which tells the browser how long to keep a file before checking for a new version (MDN). Long-lived assets that rarely change (images, fonts) can be cached for a year; files that change more often (CSS, JS) for a shorter period, ideally with versioned filenames so updates still reach users.

How do you set Cache-Control headers?

You set Cache-Control headers in your server configuration, telling browsers how long to cache each file type, with long durations for assets that rarely change and shorter ones for those that do. The setup differs slightly between Apache and Nginx, but the principle is the same.

On Apache, you add rules to your .htaccess file:

<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresByType image/png "access plus 1 year"
  ExpiresByType text/css "access plus 1 month"
  ExpiresByType application/javascript "access plus 1 month"
  ExpiresByType text/html "access plus 1 hour"
</IfModule>

On Nginx, you add location blocks to your server config:

location ~* \.(jpg|jpeg|png|gif|ico|woff2)$ { expires 1y; add_header Cache-Control "public"; }
location ~* \.(css|js)$ { expires 1M; add_header Cache-Control "public"; }

After editing, save and reload the server. The result is that repeat visitors download far less, since their browser already holds your stable assets, which directly improves perceived speed and your Lighthouse score. If you use a CDN or a caching plugin, it often manages these headers for you, so check its settings before hand-editing config.

How do you optimise JavaScript for a better score?

You optimise JavaScript by loading only what’s needed, when it’s needed, and keeping files small, which cuts the Total Blocking Time that drags Lighthouse scores down. JavaScript is the most common cause of a poor performance score, because the browser has to download, parse, and run it before the page can respond.

Work through these in order:

• Defer and async non-critical scripts. The default <script> tag blocks rendering; defer runs the script after the HTML is parsed (in order), and async runs it as soon as it loads (MDN).

<script src="/js/app.js" defer></script>
<script src="/js/analytics.js" async></script>

• Load scripts conditionally. Don’t load everything up front; load a feature’s script only when it’s actually needed, for example when the user scrolls to it or opens a component. This keeps the initial load light.
• Minify and bundle. Minification strips whitespace and comments to shrink files; bundling combines them to reduce requests. Build tools like Webpack or Vite handle both automatically.
• Remove unused JavaScript. Code the page never runs is pure cost; our guide to reducing unused JavaScript covers how to find and cut it, and eliminating render-blocking resources covers the deferral side in depth.

Together these reduce how much the main thread has to do during load, which is exactly what lowers Total Blocking Time and lifts the score.

How do you optimise images for a better score?

After JavaScript, images are the most common thing dragging a Lighthouse score down, because they’re often the largest, heaviest resources on the page, and the LCP element itself is usually an image. Three techniques cover most of the win: modern formats, lazy loading, and responsive sizing.

• Serve modern formats. WebP and AVIF compress far smaller than JPEG or PNG at the same quality, so converting images is one of the biggest, easiest savings, and Lighthouse flags it directly with its “Serve images in next-gen formats” audit (web.dev).
• Lazy-load offscreen images. Add loading="lazy" so below-the-fold images load only as the user scrolls rather than all at once, but never lazy-load your LCP or above-the-fold image, which would delay the very thing Lighthouse measures.
• Serve responsive images. Use srcset so each device downloads an appropriately sized image instead of one huge file that wastes bandwidth on small screens.

A typical responsive, lazy-loaded image looks like this:

<img src="hero-800.webp" srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1200.webp 1200w" sizes="(max-width: 600px) 400px, 800px" width="800" height="500" alt="..." loading="lazy">

Note the explicit width and height: setting them lets the browser reserve space and avoid layout shift (helping CLS) while the image loads. Compress everything before upload, and if you’re on WordPress, an image plugin or your CDN can generate WebP or AVIF and the right sizes automatically. For more on choosing formats, see our guide to image file types.

How do you eliminate render-blocking CSS and fonts?

Render-blocking resources are CSS and fonts the browser must fetch and process before it can paint anything, so they directly delay how fast your page appears and are a frequent Lighthouse flag (Chrome). Clearing them is mostly about loading the critical bits first and deferring the rest.

For CSS, inline the small amount of “critical” CSS needed to render the top of the page directly in the HTML, then load the full stylesheet without blocking, and minify what you ship. For fonts, the two highest-impact steps are preloading the fonts used above the fold so the browser fetches them early, and setting font-display: swap so text shows immediately in a fallback rather than staying invisible while the custom font loads:

<link rel="preload" href="/fonts/brand.woff2" as="font" type="font/woff2" crossorigin>

Preloading tells the browser to start fetching the font right away instead of discovering it late in the CSS, and font-display: swap (set in your @font-face rule) prevents the invisible-text delay that hurts perceived speed. Together with deferring non-critical JavaScript, this clears the path to first paint, which is exactly what lifts LCP and your score. Our guide to eliminating render-blocking resources goes deeper on the technique.

How do you keep performance high over time?

You keep performance high by monitoring it regularly, because new plugins, scripts, and content quietly erode speed if no one watches. A good score is a moment-in-time result; staying fast is a habit, not a one-off fix.

Build a simple routine: run Lighthouse after any significant change (a redesign, a new plugin, added third-party tags) and watch your Core Web Vitals in PageSpeed Insights and Search Console, which show real-user field data rather than a single lab test. Set a performance budget, a cap on page weight and script size, and treat anything that breaches it as a regression to fix. Keep removing unused code, re-checking that caching is working, and confirming fixes in the field over the weeks after you ship them. Third-party scripts are a frequent culprit for creeping slowdowns, which our guide to minimising third-party impact addresses directly. The discipline of measure, fix, re-measure is what keeps a fast site fast.

Final thoughts

Improving your Lighthouse performance score comes down to understanding what it measures, the same loading and responsiveness signals as Core Web Vitals, then fixing the issues it flags. For most sites the two biggest wins are caching static assets with proper Cache-Control headers and optimising JavaScript by deferring, lazy-loading, minifying, and removing what isn’t used.

Treat the score as a diagnostic, not a trophy: fix the largest opportunities first, confirm improvements in real-user field data, and set a performance budget so the gains don’t erode over time. Do that and a fast, stable page follows, which is what the score was really standing in for. For the metric-by-metric detail, pair this with our guide to improving Core Web Vitals.

What is third-party impact, and why does it matter?

Third-party impact is the performance and security cost that external scripts, analytics, ads, social widgets, chat tools, and fonts, add to your website. Each one is code loaded from someone else’s server, so it adds network requests, main-thread work, and a dependency you don’t control. These services add real value, but left unmanaged they’re one of the biggest drags on site speed, and the fix is to load only what you need, as efficiently as possible.

Key Takeaways

• 92% of pages load at least one third party, and the median page makes 79 third-party requests on mobile (HTTP Archive Web Almanac, 2025).
• Third-party scripts are a leading cause of poor responsiveness: pages with heavy user-tracking scripts keep good INP only 37% of the time on mobile (Web Almanac, 2024).
• You manage them by auditing, prioritising, deferring, self-hosting where sensible, and setting a performance budget.
• Security tools (CSP and SRI) limit the damage a compromised third party can do.

Almost every site depends on third parties, and most depend on dozens. The problem isn’t using them, it’s using more than you need and loading them in ways that block your own content. This guide shows how to find your third-party scripts and reduce their impact on speed and security, building on our wider guide to improving Core Web Vitals.

How do you identify third-party scripts on your site?

You identify third-party scripts using your browser’s developer tools and free auditing tools, which list every external resource your page loads. You can’t reduce what you can’t see, so this is always the first step.

Three practical methods:

• Browser DevTools. Open Chrome DevTools (Cmd+Option+I on Mac, Ctrl+Shift+I on Windows), go to the Network tab, and reload. Sort by domain and anything not on your own domain is a third party. The Performance panel shows which of them occupy the main thread.
• Lighthouse and PageSpeed Insights. Both run a “Reduce the impact of third-party code” audit that lists each third party with its transfer size and main-thread blocking time, so you can see which ones cost the most.
• Your CMS plugins. On WordPress and similar, many plugins inject third-party scripts site-wide. Review each plugin’s settings, because plugins are where unexpected third parties usually creep in.

This matters because third parties compound: the median inclusion-chain depth is 3, meaning the scripts you add often pull in further scripts of their own (HTTP Archive Web Almanac, 2025). One tag can quietly become several.

How do you prioritise and remove non-essential services?

You prioritise third-party services by ranking each one against its performance cost, then removing or replacing the ones that aren’t worth what they slow down. Not every service earns its place, and the audit usually surfaces a few you can drop outright.

Work through a simple process. List every third party you found. For each, ask what it genuinely does for the business: is it core (payments, essential analytics) or merely nice-to-have (a second analytics tool, a rarely used widget)? Then check its cost in Lighthouse, which shows the main-thread time each one adds. Where a heavy service isn’t essential, remove it; where a lighter alternative exists (a privacy-friendly analytics tool in place of a heavy one), switch. Anything that survives but isn’t needed immediately should be deferred or lazy-loaded rather than loaded up front.

The payoff is concentrated in responsiveness. Tracking and consent scripts are among the worst offenders for Interaction to Next Paint: only 37% of mobile pages with user-behaviour scripts keep good INP, and consent-management scripts drop good-INP rates to 53% on mobile (Web Almanac, 2024). Cutting or deferring these often improves the metric Google now grades most directly.

How do you audit your tag manager?

A tag manager (like Google Tag Manager) is often where third-party scripts quietly accumulate, because marketing and analytics tags get added through it over months and the old ones never get removed. Auditing it is one of the highest-leverage clean-ups available, since a single container can be loading a dozen scripts you’ve forgotten about.

Work through the container methodically. List every tag, then for each ask whether it’s still used, who owns it, and whether it still fires on the right pages, paused campaigns, expired pixels, and abandoned A/B tests are common dead weight. Remove anything that no longer earns its place, and consolidate duplicates (two analytics tools doing the same job, say). Check firing triggers too: a tag set to fire on “all pages” that’s only needed at checkout is loading everywhere for no reason, so scope each trigger tightly. Finally, treat the tag manager itself as a third party with a budget, every new tag request should justify its cost before it goes in, because the container is only as fast as the sum of what it loads. A quarterly tag audit stops the slow accumulation that turns a fast site sluggish.

How do you load third-party scripts efficiently?

You load third-party scripts efficiently by using async and defer so they don’t block the page from rendering, and by lazy-loading anything that isn’t needed at first paint. The default <script> tag is render-blocking; these attributes change that.

The two attributes behave differently (MDN). With async, the script downloads in parallel and runs as soon as it’s ready, in no guaranteed order, which suits independent scripts like analytics. With defer, the script downloads in parallel but runs only after the HTML is parsed, in document order, which suits scripts that depend on page elements being present.

<script src="https://example.com/analytics.js" async></script>
<script src="https://example.com/widget.js" defer></script>

Beyond those attributes, lazy-load non-critical embeds (a social feed or map) so they load only when the user scrolls to them, and combine or remove duplicate tags to cut request count. This matters because blocking work is already high: median mobile Total Blocking Time is around 1,209 ms, roughly six times the recommended threshold (Web Almanac, 2024), and third-party scripts are a major contributor. Deferring them is one of the most direct ways to bring it down. For the related problem of your own blocking files, see our guide to eliminating render-blocking resources.

Should you self-host third-party scripts or use a CDN?

You should self-host third-party scripts when you safely can, and use a CDN to serve your own and static assets quickly, because both reduce the cost of fetching from many external servers. Each extra domain your page contacts adds a DNS lookup and a new connection, so consolidating where you can speeds things up.

Self-hosting means downloading a stable third-party file and serving it from your own server. The benefits are faster, more predictable delivery, full control over the version, and resilience if the third party’s server goes down. The caveat is maintenance: you become responsible for updates, so self-host scripts that change rarely, not ones the vendor updates constantly (like a live tag manager). A CDN, by contrast, serves your files from a server geographically near each visitor, which cuts latency and absorbs traffic spikes, and most CDNs add security features like DDoS protection. Reducing the number of distinct domains your page calls, and prefetching DNS for the ones that remain with <link rel="dns-prefetch">, trims the connection overhead further.

How do you protect security with CSP and SRI?

You protect against malicious or compromised third parties with a Content Security Policy (CSP) and Subresource Integrity (SRI), two browser mechanisms that limit what external code can do. Every third-party script is code you didn’t write running on your page, so these controls matter as much as speed.

A Content Security Policy tells the browser which sources are allowed to load resources, which helps prevent cross-site scripting and limits the blast radius if a third party turns malicious (MDN). You set it as an HTTP header listing trusted sources:

Content-Security-Policy: script-src 'self' https://trusted-cdn.com;

Subresource Integrity verifies that a file fetched from a third party hasn’t been altered, by checking it against a cryptographic hash (sha256, sha384, or sha512) you specify; if the file changes, the browser refuses to run it (MDN). You add the hash with the integrity attribute, plus crossorigin for cross-origin files:

<script src="https://trusted-cdn.com/lib.js" integrity="sha384-abc123" crossorigin="anonymous"></script>

Together they mean that even if a third party is compromised, it can’t easily inject new code or silently swap a file you trusted.

How do you monitor third-party performance over time?

You monitor third-party impact by testing regularly with performance tools and setting a performance budget so new scripts can’t quietly degrade your site. Third parties accumulate over time, so a one-off cleanup isn’t enough; you need a habit.

Use Lighthouse, PageSpeed Insights, or GTmetrix to track your Core Web Vitals and the third-party breakdown after any significant change. Watch the three current thresholds: LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less, all measured at the 75th percentile of real users (web.dev). Note that INP replaced the older First Input Delay metric as a Core Web Vital on 12 March 2024 (web.dev), so if your tooling still references FID, it’s out of date. Then set a performance budget, a cap on third-party size and count, and treat any new tag as a request that has to fit within it. That single discipline stops the slow creep that turns a fast site into a slow one.

What is a performance budget, and how do you set one?

A performance budget is a set of limits you agree for your pages, on size, requests, or timing, that any change has to stay within, so performance can’t quietly degrade as you add features and scripts (web.dev). It turns “keep the site fast” from a vague aim into a concrete rule you can check against.

Budgets come in three flavours, and most teams use a mix. Quantity-based budgets cap things you can count: total page weight (for example, “under 1.5MB”), the number of requests, or the size of third-party JavaScript specifically. Milestone-based budgets cap timings, such as “LCP under 2.5 seconds” or a minimum Lighthouse score. Rule-based budgets are pass/fail checks (no render-blocking resources, images served as WebP or AVIF). To set one, measure your current numbers as a baseline, agree a realistic limit slightly tighter than today (or matched to your Core Web Vitals targets), and write it down where the team can see it. Then enforce it: many teams wire a budget check into their build or use Lighthouse CI, so a change that blows the budget fails automatically. For third parties specifically, a budget is the discipline that stops the next “just one more tag” from being the one that tips your INP into the red.

Final thoughts

Third-party scripts are unavoidable and genuinely useful, but they’re also one of the heaviest, least-noticed costs on the modern web: the median page loads dozens of them, and the worst offenders quietly wreck responsiveness. The goal isn’t to remove them all, it’s to keep only what earns its place and load it without blocking your own content.

Audit what you have, drop the non-essential, defer and lazy-load the rest, self-host stable files, and protect yourself with CSP and SRI. Then set a performance budget so the problem doesn’t return. Do that and your third parties add value without dragging your site down. For the full performance picture, pair this with our guides to improving Core Web Vitals and reducing unused JavaScript.

SEO tag optimization is the practice of writing the HTML signals Google reads first, the title tag, meta description, headings, image alt text, schema, canonical and hreflang, so that the right page wins the right query and the snippet that lands in the SERP is the one you wrote. Most sites lose visibility not because the content is weak, but because the tags are missing, wrong, or contradicting each other.

Key Takeaways

• Google rewrites the title tag on 33.4% of pages and the meta description on 62.78% of pages, and shows the meta description in results only 37.22% of the time (Ahrefs SEO Statistics, 2024).
• 98% of pages now use a title tag and 70% use an H1, but only 66.7% of desktop pages have a meta description (Web Almanac 2024, SEO chapter).
• 80.4% of sites have missing image alt attributes and over 67% of domains using hreflang have implementation issues (Ahrefs SEO Statistics, 2024).

!SEO tag optimization for a webpage, including title, meta description, headings and schema

What counts as an SEO tag?

An SEO tag is any HTML element in the <head> or page body that search engines use to interpret or display the page. Google’s own documentation lists the elements it acts on: the <title>, meta description, headings, image alt attributes, structured data (schema.org), canonical link, hreflang, robots directives and Open Graph or Twitter card meta for social previews (Google Search Central, Title link best practices).

Not every meta tag matters. Google confirmed years ago that the meta keywords element is ignored, and the meta viewport is a rendering signal rather than a ranking one. The eight tags below are the ones that change what Google indexes, what it shows, and what gets clicked.

Why does the title tag still do the heaviest lifting?

The title tag is the single highest-impact tag on the page, and it’s also the one Google is most likely to override. Ahrefs’ 2024 statistics study found Google rewrites the title shown in the SERP on 33.4% of pages, and when it does, it pulls from the H1 50.76% of the time (Ahrefs SEO Statistics, 2024). The fix isn’t to give up on writing titles, it’s to write titles Google has no reason to replace.

Google’s own documentation tells you what triggers a rewrite: titles that are too long, stuffed with repeated keywords, or boilerplate across multiple pages (Google Search Central, Title link best practices). A title that’s specific, descriptive, and under the typical SERP width survives untouched.

“`html

What length should a title tag be?

Google does not enforce a character limit. The 50 to 60 character figure most guides repeat is a rendering rule, not an algorithmic one. Google truncates titles to fit the device width, so a desktop SERP will show roughly 600 pixels of title and a mobile SERP slightly less. The table below shows typical SERP rendering widths based on Web Almanac and SEO platform data.

Source: Web Almanac 2024, SEO chapter. The median title is significantly longer than the visible SERP width, which is why Google rewrites a third of them. Aim for the practical target and you stop relying on Google to guess.

When does Google actually show your meta description?

Google shows the meta description you wrote on only 37.22% of pages, and rewrites the rest from page content (Ahrefs SEO Statistics, 2024). Google’s official line is that the meta description is used “when it might give users a more accurate description of the page than content taken directly from the page” (Google Search Central, Snippet documentation). In practice that means: write it for the query, not for the page.

The Web Almanac 2024 SEO chapter reports the median meta description has doubled in two years, from 19 words in 2022 to 40 words in 2024, with median character count now at 272 (Web Almanac 2024). That’s longer than what Google typically renders in the SERP, but the extra room helps Google match your description against more queries.

“`html

Three rules that lift the chance Google keeps your description:

• Include the query. If your target query doesn’t appear in the description, Google is more likely to substitute body copy that does.
• Front-load the answer. The first 120 characters carry the SERP. Put the value there.
• One per page. Web Almanac data shows duplicate descriptions across templates is the most common error.

How important is the H1 and heading hierarchy?

H1 placement is now more about disambiguation than ranking. When Google ignores your title tag, it uses your H1 to generate the SERP title in 50.76% of cases (Ahrefs SEO Statistics, 2024). That makes the H1 a backup title, not just a heading. 59.5% of sites have missing H1 tags and 51.3% have multiple H1s, which is two of the most common SEO audit findings in the same Ahrefs dataset.

The fix is one H1 per page, written like a short version of the title:

“`html

SEO Tag Optimization: Title, Meta, Schema, Canonical & Hreflang

What counts as an SEO tag?

…sub-points belong here, not as a second H1

Multiple H1s won’t break ranking on their own, John Mueller said as much in 2019, but they confuse assistive technology and they invite Google to pick the wrong one for the SERP. Keep one.

What does schema markup actually do for visibility?

Schema markup tells Google what a page is, in machine-readable JSON-LD, so it can build rich results around it. Google’s own case studies put the click-through lift at 25% for Rotten Tomatoes across 100,000 enhanced pages and 82% for Nestlé on pages that earn rich results (Google Search Central, Intro to structured data). The format Google recommends is JSON-LD, embedded in a <script> tag in the head or body.

“html “

The schema types worth implementing depend on what you publish. Use the table below to match common page types to the schema Google currently builds rich results for.

Source: Google Search Central, Search gallery. FAQ rich results were narrowed in Google’s August 2023 update, so don’t expect the FAQ snippet on a generic commercial page anymore. The schema still helps Google understand the content.

Why is image alt text the most-skipped on-page win?

Because most CMS templates make it optional, and 80.4% of sites end up with missing alt attributes (Ahrefs SEO Statistics, 2024). The Web Almanac 2024 study found that the median mobile site only has alt text on 58% of its images, and 14% of pages now ship explicitly empty alt="" values, often auto-generated by the CMS (Web Almanac 2024).

Alt text serves two distinct purposes: it’s read aloud by screen readers, and it’s what Google uses to understand image content for Google Images and AI Overviews. The rule is description, not keyword:

“`html

Decorative images, dividers, background graphics, take alt="" so screen readers skip them. Functional images, icons that act as buttons, take a description of the action. Content images take a description of the content.

How do canonical tags and hreflang fail in practice?

Canonical and hreflang are the two head-level tags most likely to be broken silently. The 2024 Web Almanac reports 65% of mobile and 69% of desktop pages now use a canonical tag, up from 61 and 59% in 2022, but 0.8% have conflicting canonical values inside the same page and 2.1% of mobile pages see the canonical change after JavaScript rendering (Web Almanac 2024). Hreflang is worse: Ahrefs found over 67% of domains using hreflang have implementation issues (Ahrefs SEO Statistics, 2024).

“`html

Three rules from Google’s documentation that cover most failure modes:

• Canonical is a strong signal, not a directive. Google may still pick a different URL if your internal linking, sitemap, or hreflang point elsewhere. Don’t combine noindex with a canonical; they cancel each other out (Google Search Central, Consolidate duplicate URLs).
• Hreflang must be bidirectional. If page A points to page B with hreflang, page B must point back to page A. Missing return tags are why most hreflang setups are ignored (Google Search Central, Localized versions).
• Use full URLs, not paths. Both canonical and hreflang require absolute URLs including the protocol.

Where do robots, Open Graph and Twitter card tags fit?

These are the three tags that don’t rank you, but they decide whether you get indexed and how you look when shared. The robots meta is the most consequential of the three because it’s the one that can quietly de-index your entire blog.

“`html

The most common destructive accident is shipping a staging-environment noindex, nofollow to production. Check your robots meta and your robots.txt after every redeploy. The most common Open Graph mistake is the missing or wrong og:image, since social platforms cache aggressively and a fix can take 24 hours to propagate.

Has mobile-first indexing changed which tags matter?

Yes, in one specific way: Google now crawls almost exclusively with the smartphone Googlebot, which means the tags in your mobile rendering are the ones that count (Google Search Central, Mobile-first indexing). Mobile-first is the default for Search.

The practical implications for tag work:

• If your mobile template strips structured data, the schema doesn’t exist as far as Google is concerned.
• If your mobile template shortens the title or hides the H1, Googlebot sees the shorter version.
• If your mobile template injects a different canonical than your desktop template, Google may pick either, and the mobile version wins more often.

Render the page in a mobile user agent (Chrome DevTools, Lighthouse, or Google’s URL Inspection Tool in Search Console) and view the rendered HTML. The tags you see there are the tags Google sees.

A 12-point tag audit you can run in 20 minutes

Open the page in Chrome, view source, then check each item in order. This catches the failures that account for most lost visibility in the studies above.

1. Is there exactly one <title> tag, under 60 characters, with the primary keyword in the first 50?
2. Is there exactly one <meta name="description">, between 120 and 270 characters, including the target query?
3. Is there exactly one <h1>, not duplicated as a second H1 lower in the page?
4. Do all heading levels descend (H1 then H2 then H3) without skipping levels?
5. Do all content images have a descriptive alt attribute? Decorative images, alt=""?
6. Is there exactly one <link rel="canonical"> with a full URL pointing to the current page (or its master version)?
7. Are all hreflang tags bidirectional and using absolute URLs with valid language codes?
8. Is the robots meta index, follow on pages that should rank? Is the staging noindex removed?
9. Is there valid JSON-LD schema for the page type (Article, Product, LocalBusiness)?
10. Are Open Graph og:title, og:description, og:image and og:url present?
11. Does twitter:card exist, ideally as summary_large_image?
12. Does the mobile rendering preserve all of the above? (View Source on mobile, or use Google’s URL Inspection Tool.)

What this means in practice

If you only have time for three changes this week, do these in order. Write the title and meta description for the target query, not the page name, and check that both survive Google’s rewrite by searching the URL site:operator and reading the SERP. Add or fix one schema type per page template, starting with BlogPosting for articles and Product for product pages. Run a 12-point audit on your top 20 pages and fix the canonical, hreflang and robots meta failures first, since those control whether the page ranks at all. The tags above are what Google reads before anything else on your site; getting them right is the cheapest visibility work in SEO.

How do you choose the right web hosting?

You choose the right web hosting by matching the hosting type to your site’s traffic, budget, and how much control and technical skill you have. The choice matters because your host determines how fast your server responds, and a slow server response, measured as Time to First Byte, drags down every page; a good TTFB is 0.8 seconds or less (web.dev). The main types, shared, VPS, dedicated, cloud, and managed WordPress, suit very different needs, and this guide explains each so you can pick well.

Key Takeaways

• The main hosting types are shared, VPS, dedicated, cloud, and managed WordPress, each balancing cost, control, and performance differently.
• Your host affects server response time (TTFB), where good is 0.8 seconds or less, so it directly shapes page speed (web.dev).
• Shared hosting is cheapest and best for small sites; dedicated and cloud suit high traffic and demanding sites.
• Match the type to your traffic, budget, technical skill, and growth plans, not to the lowest price alone.
• You can start small and upgrade as your site grows; hosting isn’t a permanent decision.

Because hosting underpins site speed, this pairs with our guides to fixing slow website speeds and improving Core Web Vitals.

What is web hosting and why does the type matter?

Web hosting is the service that stores your website’s files on a server and makes them available to visitors over the internet (MDN). Every website needs hosting, but the type you choose determines how much server power, control, and reliability you get.

The type matters for three reasons. Performance: how quickly the server responds to requests affects your page speed and Core Web Vitals, and an overloaded shared server responds more slowly than a dedicated or well-provisioned one. Reliability: better hosting types offer more uptime and handle traffic spikes without crashing, which matters when a campaign or a busy season sends visitors your way. And control: some types let you configure the server fully, while others manage it for you in exchange for less flexibility. Choosing the wrong type means either paying for power you don’t need or throttling a growing site on resources it has outgrown.

What are the main types of web hosting?

The main types are shared, VPS, dedicated, cloud, and managed WordPress hosting, ranging from cheap and hands-off to high-capacity and fully configurable (MDN). Each represents a different trade-off between cost, control, and performance. The table below compares them at a glance.

What is shared hosting?

Shared hosting puts many websites on a single server, splitting its resources between them, which makes it the cheapest option and the usual starting point for small sites and blogs. The trade-off is the “noisy neighbour” effect: if another site on the server has a traffic surge, your site can slow down too. It’s ideal for low-traffic sites where budget matters most, but sites that grow tend to outgrow it.

What is VPS hosting?

A virtual private server (VPS) divides a physical server into isolated virtual ones, giving you a guaranteed slice of resources and more control than shared hosting. Your performance no longer depends on other sites, and you can configure the environment more freely. It suits growing sites that need more power and consistency, though it usually expects a little more technical knowledge to manage.

What is dedicated hosting?

Dedicated hosting gives you an entire physical server to yourself, with full control over its resources and configuration. It delivers the most power and the most flexibility, which suits high-traffic sites and demanding applications, but it’s the most expensive option and typically requires real server-administration skill. Most sites don’t need dedicated hosting until they’re large.

What is cloud hosting?

Cloud hosting runs your site across a network of connected servers rather than one machine, so it can scale resources up or down on demand and stay online if one server fails. You generally pay for what you use, which makes it cost-effective for variable traffic and resilient against spikes. It’s a strong fit for sites with unpredictable or growing traffic that value reliability and flexibility.

What is managed WordPress hosting?

Managed WordPress hosting is optimised specifically for WordPress, with the host handling updates, security, backups, and performance tuning for you. You trade some flexibility for convenience and a server environment tuned for WordPress, which often means better speed and fewer maintenance headaches. It suits WordPress site owners who’d rather focus on their content and business than on server management.

How do you match hosting to your website’s needs?

You match hosting to your needs by weighing four things: your expected traffic, your budget, your technical skill, and your growth plans (web.dev). Starting from these rather than from price alone leads to a host that fits rather than one you quickly outgrow or overpay for.

Work through them in order. Traffic is first: a small blog runs fine on shared hosting, while a busy store or app needs VPS, cloud, or dedicated resources to stay fast under load. Budget is real, but treat it alongside performance, since a host that’s too weak costs you visitors and conversions through slow pages. Technical skill matters because dedicated and unmanaged VPS hosting expect you to administer the server, whereas shared and managed options handle that for you. And growth plans matter because choosing a type that can scale, or a host that makes upgrading easy, saves a painful migration later. If you run WordPress and don’t want to manage servers, managed WordPress hosting often gives the best balance of speed and simplicity.

When should you upgrade your hosting?

You should upgrade when your site consistently outgrows its current resources, which usually shows up as slow pages, downtime during traffic spikes, or hitting your plan’s limits (web.dev). Hosting isn’t a one-time decision; the right type early on is often the wrong one once a site grows.

Watch for a few clear signals. Pages loading slowly despite optimisation, especially a poor Time to First Byte, can mean an overloaded shared server. Your site going down or crawling when traffic peaks suggests you’ve outgrown your resources. Repeatedly hitting storage, bandwidth, or resource caps on your plan is another sign. And a growing, revenue-generating site simply justifies investing in faster, more reliable hosting. The good news is that upgrading is normal and expected: many sites start on shared hosting and move to VPS, cloud, or managed hosting as they grow. If slow speed is your main symptom, our guide to fixing slow website speeds helps you confirm whether hosting is the cause before you switch.

What makes Facebook advertising effective?

Effective Facebook advertising comes from matching the right ad to the right audience and measuring the result, not from spend alone. The platform’s value is its targeting: you can put a relevant message in front of precisely the people most likely to act, then track what they do. As organic reach has declined, paid ads have become the reliable way to get results on Facebook, and the businesses that win are the ones who treat advertising as a measure-and-refine loop.

Key Takeaways

• Facebook is reachable with ads by about 2.28 billion users, and 70% of marketing leaders report positive ROI from it (DataReportal, 2025; Sprout Social, 2026).
• The metrics that matter are cost per result, ROAS, conversion rate, and engagement, not vanity likes.
• Facebook retired the single 1-10 relevance score; ads are now graded on three relevance diagnostics.
• Good ads combine clear copy, a strong visual, precise targeting, and constant testing.

Facebook advertising rewards clarity and discipline more than budget. A small, well-targeted, well-measured campaign routinely beats a larger, vaguer one. This guide covers the strategy side, ad types, metrics, copy and design, and B2B versus B2C, and works alongside our practical guide to the Facebook Ad Manager tool and our overview of Facebook for business.

What types of Facebook ads can you run?

The main Facebook ad types are in-feed ads, image, video, carousel, and collection, that appear naturally as people scroll, supported by formats for Stories and Reels. In-feed ads are the workhorses because they sit among the content people already engage with, making them visible without being intrusive.

In-feed ads can be a boosted organic post or an ad built specifically in Ads Manager, and they come in several formats: a single image for simplicity, video for engagement and storytelling, carousel for showing multiple products or steps, and collection for a shoppable, catalog-style experience. Stories and Reels add full-screen, short-form placements suited to vertical video. (The older right-hand-column ad, which sat beside the feed on desktop, still exists but is now a limited, desktop-only placement, not a primary one.) Choosing the format is really about matching the medium to the message: video to tell a story, carousel to show a range, a single strong image when the message is simple. For the full format and placement detail, see our Facebook Ad Manager guide.

Which metrics actually matter?

The metrics that matter are the ones tied to business outcomes: cost per result, return on ad spend (ROAS), conversion rate, and meaningful engagement, not raw likes. Likes feel good but rarely pay; these numbers tell you whether your spend is working.

Group them into three:

• Results and conversions: the actions you actually want, purchases, leads, sign-ups, and the conversion rate (the share of clicks that complete the action). This is the headline of whether an ad works.
• Cost: cost per result (total spend divided by results) and ROAS (revenue divided by ad spend). ROAS above your break-even point is the signal to scale; below it is the signal to fix or stop.
• Engagement: likes, comments, shares, and video views. These matter mainly as a leading indicator, strong engagement often improves delivery efficiency and signals that your creative resonates, but engagement without conversions isn’t success.

Watch cost per result and ROAS most closely, because they tell you directly whether the campaign makes money. Engagement and conversion rate then tell you why, and what to adjust.

How do you create a high-performing Facebook ad?

You create a high-performing ad by combining clear, benefit-led copy, a strong visual, precise targeting, and a single obvious call to action, then testing variations. Each element supports the others; a great image with weak targeting, or sharp targeting with muddled copy, underperforms.

On copy, be concise and lead with the benefit to the customer, not a list of features. Name the problem you solve, state the value plainly, and include one clear call to action (“Shop now,” “Get a quote,” “Learn more”). On design, use a high-quality image or video, keep it on-brand, design for mobile first since that’s where most people see it, and let the visual carry attention while the copy explains. On targeting, reach the right people using demographics, interests, behaviours, and especially Custom and Lookalike Audiences built from your own data. Then test: run A/B variations of copy, creative, and audience, and let results decide. The single highest-impact habit in Facebook advertising is to keep testing and double down on what converts.

How does Facebook grade your ad relevance now?

Facebook no longer uses a single 1-10 relevance score; it grades ads with three separate relevance diagnostics, and understanding them tells you what to fix. The old score was retired in 2019 and replaced by a more useful breakdown (Meta).

The three diagnostics each isolate a different problem. Quality ranking compares your ad’s perceived quality against others competing for the same audience. Engagement rate ranking compares its expected engagement. Conversion rate ranking compares its expected conversion against ads with the same optimisation goal. The value is diagnostic: a low quality ranking points to weak creative; a low engagement ranking points to a message that doesn’t resonate; a low conversion ranking points to a landing-page or offer problem. Higher relevance generally means lower costs and better delivery, so improving whichever ranking is weak is one of the most cost-effective optimisations available, and far more actionable than chasing a single mystery number.

How does strategy differ for B2B vs B2C?

Facebook advertising works for both B2B and B2C, but the strategy differs: B2C focuses on direct product appeal and impulse, while B2B focuses on lead generation and longer-term relationship building. The targeting tools are the same; how you use them and what you ask for differ.

B2C advertising tends to be product-led, attracting consumers with compelling visuals, offers, and a quick path to purchase, often optimising for the Sales objective. B2B advertising usually optimises for Leads, using thought-leadership content, gated resources, and lead forms to start a relationship that closes elsewhere, since the buying cycle is longer and involves more people. Both benefit from Facebook’s precise targeting, and both gain from the Instagram connection: because Facebook owns Instagram, one campaign can run across both platforms, extending reach to Instagram’s younger, highly engaged audience. Deciding how to split effort between them is worth thinking through with our Instagram vs Facebook comparison.

What’s the difference between retargeting warm and cold audiences?

Retargeting is advertising to people based on how they’ve already interacted with you, and the core distinction is warm versus cold: cold audiences have never heard of you, while warm audiences have engaged before, and the two need different messages. Treating them the same is a common reason ad budgets underperform.

Cold audiences are new prospects, reached through interest, behaviour, or Lookalike targeting. The job here is to introduce yourself, so the creative leads with the problem you solve and builds awareness rather than pushing for an immediate sale. Warm audiences are people who’ve already shown interest, website visitors (captured via the Meta Pixel), people who engaged with your posts or videos, your email list uploaded as a Custom Audience, or past customers. Because they already know you, retargeting them with something specific, a reminder of a product they viewed, an offer, or social proof, converts far more efficiently and at a lower cost per result.

The practical strategy is a funnel: use cold campaigns to fill the top (awareness and traffic), then retarget the warm audiences those campaigns create with conversion-focused ads. A classic high-return retargeting play is showing an offer to people who added to cart but didn’t buy. Build your warm audiences deliberately with the Meta Pixel and Custom Audiences so you always have someone to retarget, because warm retargeting is usually the most profitable spend in the account. That accuracy depends on good tracking, which is why pairing the Meta Pixel with the Conversions API matters.

Final thoughts

Effective Facebook advertising isn’t about the biggest budget; it’s about putting a clear, relevant message in front of the right audience and measuring what comes back. As organic reach has faded, paid ads have become the dependable route to results, and Facebook’s targeting and reach make that route hard to match.

Lead with benefit-driven copy and strong visuals, target precisely using your own data, watch cost per result and ROAS, and use the three relevance diagnostics to fix what’s weak. Above all, keep testing and scale what converts. For the tool that runs it all, see our Facebook Ad Manager guide, and for the wider toolkit, our overview of Facebook for business.