TL;DR
Your Shopify theme.liquid file controls every page's <head> section — which means it controls how search engines see your entire store. I've compiled 10 optimizations that can take a Dawn theme from a 65 Lighthouse score to 90+. Each includes copy-paste Liquid code, an explanation of what it does, and what can go wrong. Total implementation time: 2-4 hours.
I've audited hundreds of Shopify stores through SEOJuice. The pattern is always the same: the store owner picked a theme, customized the colors, uploaded products, and never touched theme.liquid. Meanwhile, their competitor with the same products and half the backlinks is outranking them because their developer spent an afternoon optimizing the theme code.
The Shopify Dawn theme scores 92 on PageSpeed out of the box — the fastest free Shopify theme available. But "out of the box" still leaves significant SEO wins on the table. Missing schema markup. Unoptimized font loading. No preconnect hints. Incomplete OG tags.
This guide fixes all of that. And this next section -- canonical tags -- is the one I wish every Shopify store owner understood before they came to me wondering why Google was indexing the wrong version of their product pages.
If you're not a developer, here's the 30-second version: theme.liquid is the master template file that wraps every single page in your Shopify store. It defines the <html>, <head>, and <body> structure. Every product page, collection page, blog post, and homepage inherits from this file.
When you add something to theme.liquid's <head> section, it appears on every page. That makes it the perfect place for:
To edit it: Shopify Admin → Online Store → Themes → Edit Code → Layout → theme.liquid
Key Takeaway
Always duplicate your theme before editing. Go to Online Store → Themes → Actions → Duplicate. Work on the copy. If something breaks, you can switch back instantly.
Here's what we're implementing, where it goes, and what it'll do for you:
| Optimization | Where to Add | SEO Impact | Difficulty |
|---|---|---|---|
| Canonical tags | theme.liquid <head> | High — prevents duplicate content | Easy |
| Organization schema | theme.liquid <head> | Medium — brand knowledge panel | Easy |
| Product schema | product.liquid or section | High — rich results in SERPs | Medium |
| Breadcrumb schema | Snippet + template | Medium — SERP breadcrumbs | Medium |
| Font preloading | theme.liquid <head> | High — LCP improvement | Easy |
| Critical CSS inlining | theme.liquid <head> | High — eliminates render blocking | Hard |
| Defer non-critical JS | theme.liquid <body> end | High — faster DOM parse | Medium |
| OG/Twitter meta tags | theme.liquid <head> | Medium — social sharing | Easy |
| Hreflang tags | theme.liquid <head> | High — international SEO | Medium |
| Lazy loading images | Templates/sections | Medium — reduces initial payload | Easy |
Shopify generates a lot of duplicate URLs. A product can be accessed via /products/widget and /collections/sale/products/widget — same product, two URLs. Without a canonical tag, Google sees duplicate content and may index the wrong one. I've seen stores where Google indexed the collection-path URL for every single product, which meant the "real" product URLs had zero authority.
Dawn includes basic canonical handling, but it's worth verifying and enhancing. Add this to your <head> section in theme.liquid:
{%- liquid
assign canonical_url = canonical_url | default: request.origin | append: request.path
-%}
<link rel="canonical" href="{{ canonical_url }}">
{%- if paginate and paginate.pages > 1 -%}
{%- if paginate.previous -%}
<link rel="prev" href="{{ paginate.previous.url }}">
{%- endif -%}
{%- if paginate.next -%}
<link rel="next" href="{{ paginate.next.url }}">
{%- endif -%}
{%- endif -%}This does three things: sets the canonical URL using Shopify's built-in canonical_url variable (which resolves the correct URL for products regardless of how they're accessed), adds rel="prev"/rel="next" for paginated collections, and falls back to the request origin + path if canonical_url isn't available.
Key Takeaway
Check that your theme isn't already outputting a canonical tag before adding this. Duplicate canonical tags confuse search engines more than having none at all. Search for "canonical" in your theme.liquid file first.
Organization schema tells Google who you are — your business name, logo, social profiles, and contact information. This is what powers the knowledge panel that appears when someone searches your brand name. I've watched stores go from no knowledge panel to a fully populated one within three weeks of adding this markup correctly.
Add this inside <head> in theme.liquid. It runs on every page, which is exactly what Google wants:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Organization",
"name": {{ shop.name | json }},
"url": "{{ shop.url }}",
{%- if shop.brand.logo -%}
"logo": {{ shop.brand.logo | image_url: width: 600 | json }},
{%- endif -%}
"description": {{ shop.description | json }},
"address": {
"@type": "PostalAddress",
"addressCountry": {{ shop.address.country | json }}
}
{%- if shop.brand.social_links.size > 0 -%}
,"sameAs": [
{%- for link in shop.brand.social_links -%}
{{ link | json }}{%- unless forloop.last -%},{%- endunless -%}
{%- endfor -%}
]
{%- endif -%}
}
</script>Notice I'm using the | json filter instead of | escape. This is important — json properly escapes strings for JSON-LD context, including wrapping them in quotes. Using escape in JSON-LD is a common mistake that produces invalid markup. I've debugged this specific issue on at least a dozen client stores -- the schema validates in Google's testing tool but silently fails in production because the escaping is wrong.
"JSON-LD is Google's preferred format for structured data. If you're implementing schema markup on Shopify, always choose JSON-LD over microdata — it's cleaner, easier to debug, and doesn't mix with your presentation HTML."
Product schema is what gets you those rich results in Google — star ratings, price, availability status. Dawn includes basic product schema, but it's often incomplete. Here's a comprehensive version that I've refined through testing across dozens of stores.
Create a new snippet: snippets/json-ld-product.liquid
{%- if product -%}
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Product",
"name": {{ product.title | json }},
"url": "{{ shop.url }}{{ product.url }}",
"description": {{ product.description | strip_html | truncate: 500 | json }},
{%- if product.featured_image -%}
"image": [
{{ product.featured_image | image_url: width: 1200 | json }}
{%- for image in product.images offset: 1 limit: 4 -%}
,{{ image | image_url: width: 1200 | json }}
{%- endfor -%}
],
{%- endif -%}
"brand": {
"@type": "Brand",
"name": {{ product.vendor | json }}
},
{%- if product.selected_or_first_available_variant.sku != blank -%}
"sku": {{ product.selected_or_first_available_variant.sku | json }},
{%- endif -%}
{%- if product.selected_or_first_available_variant.barcode != blank -%}
"gtin": {{ product.selected_or_first_available_variant.barcode | json }},
{%- endif -%}
"offers": {
"@type": "AggregateOffer",
"priceCurrency": {{ cart.currency.iso_code | json }},
"lowPrice": {{ product.price_min | money_without_currency | json }},
"highPrice": {{ product.price_max | money_without_currency | json }},
"offerCount": {{ product.variants.size }},
"availability": "https://schema.org/{% if product.available %}InStock{% else %}OutOfStock{% endif %}",
"url": "{{ shop.url }}{{ product.url }}"
}
{%- if product.metafields.reviews.rating.value != blank -%}
,"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": {{ product.metafields.reviews.rating.value | json }},
"reviewCount": {{ product.metafields.reviews.rating_count.value | json }}
}
{%- endif -%}
}
</script>
{%- endif -%}Then include it in your product template (usually sections/main-product.liquid or templates/product.liquid):
{% render 'json-ld-product' %}Key details: I'm using AggregateOffer instead of individual Offer objects because it's cleaner for products with multiple variants. The rating fields use Shopify's native product review metafields — if you use a third-party review app, you'll need to adjust the metafield namespace. (Judge.me and Loox use different namespaces -- check their docs before copying this verbatim.)
Breadcrumbs help Google understand your site hierarchy and can appear directly in search results, replacing the raw URL. This is especially valuable for stores with deep category structures. On one store I audited, adding breadcrumb schema changed the SERP display from example.com › collections › summer-2025 › products › red-dress to a clean Home > Summer Collection > Red Dress — which measurably improved click-through rate.
Create snippets/json-ld-breadcrumbs.liquid:
{%- assign breadcrumb_list = "" | split: "" -%}
{%- if template.name == 'product' -%}
{%- if product.collections.size > 0 -%}
{%- assign primary_collection = product.collections | first -%}
{%- capture crumb_collection -%}{"name":{{ primary_collection.title | json }},"url":"{{ shop.url }}{{ primary_collection.url }}"}{%- endcapture -%}
{%- assign breadcrumb_list = breadcrumb_list | push: crumb_collection -%}
{%- endif -%}
{%- capture crumb_product -%}{"name":{{ product.title | json }},"url":"{{ shop.url }}{{ product.url }}"}{%- endcapture -%}
{%- assign breadcrumb_list = breadcrumb_list | push: crumb_product -%}
{%- elsif template.name == 'collection' -%}
{%- capture crumb_coll -%}{"name":{{ collection.title | json }},"url":"{{ shop.url }}{{ collection.url }}"}{%- endcapture -%}
{%- assign breadcrumb_list = breadcrumb_list | push: crumb_coll -%}
{%- elsif template.name == 'article' -%}
{%- capture crumb_blog -%}{"name":{{ blog.title | json }},"url":"{{ shop.url }}{{ blog.url }}"}{%- endcapture -%}
{%- assign breadcrumb_list = breadcrumb_list | push: crumb_blog -%}
{%- capture crumb_article -%}{"name":{{ article.title | json }},"url":"{{ shop.url }}{{ article.url }}"}{%- endcapture -%}
{%- assign breadcrumb_list = breadcrumb_list | push: crumb_article -%}
{%- endif -%}
{%- if breadcrumb_list.size > 0 -%}
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "Home",
"item": "{{ shop.url }}"
}
{%- for crumb_json in breadcrumb_list -%}
,{
"@type": "ListItem",
"position": {{ forloop.index | plus: 1 }},
"name": {{ crumb_json | split: '"name":' | last | split: ',"url"' | first }},
"item": {{ crumb_json | split: '"url":' | last | split: '}' | first }}
}
{%- endfor -%}
]
}
</script>
{%- endif -%}Add {% render 'json-ld-breadcrumbs' %} in your theme.liquid right before </head>. The snippet automatically detects the page type and builds the appropriate breadcrumb chain.
This next one is the change that made the biggest difference on our test stores. Font preloading alone can shave a full second off time-to-text -- and for e-commerce, that second directly correlates with bounce rate. Shopify's own engineering team demonstrated the impact on shopify.com itself:
"With preload, front-end developers can tell the browser to download the font files needed at the same time as the CSS files. Only 17 lines of code decreased the time to display text on shopify.com by 50%."
The problem: browsers can't download fonts until they've parsed both the HTML and the CSS that references them. That's two sequential round trips before text appears. Preloading tells the browser "start downloading this font now, you'll need it soon."
Add this near the top of <head> in theme.liquid, before your stylesheet tags:
{%- comment -%}
Preload your primary heading and body fonts.
Check your theme's font settings to get the correct filenames.
Use font-display: swap in your CSS to prevent FOIT (Flash of Invisible Text).
{%- endcomment -%}
{%- if settings.type_header_font != blank -%}
<link rel="preload"
href="{{ settings.type_header_font | font_url }}"
as="font"
type="font/woff2"
crossorigin>
{%- endif -%}
{%- if settings.type_body_font != blank -%}
<link rel="preload"
href="{{ settings.type_body_font | font_url }}"
as="font"
type="font/woff2"
crossorigin>
{%- endif -%}
{%- comment -%} Preconnect to Shopify's CDN for faster asset loading {%- endcomment -%}
<link rel="preconnect" href="https://cdn.shopify.com" crossorigin>
<link rel="preconnect" href="https://fonts.shopifycdn.com" crossorigin>The crossorigin attribute is required for font preloads — without it, the browser downloads the font twice. I've seen this exact mistake on production stores, where removing the duplicate download alone improved LCP by 400ms. The preconnect hints save an additional ~100ms by establishing the TCP + TLS connection to Shopify's CDN early.
Key Takeaway
Only preload fonts you use above the fold. Every preload competes for bandwidth. If you preload five fonts, you've defeated the purpose — the browser will download all five in parallel, slowing everything else down.
Render-blocking CSS is the #1 reason Shopify stores score poorly on Lighthouse. The browser can't paint anything until it downloads and parses your entire stylesheet — even the CSS for the footer that's 3,000px below the fold. This is the hardest optimization on this list, but it consistently delivers the largest Lighthouse improvement I've seen across audits.
The fix: inline the CSS needed for above-the-fold content directly into <head>, and load the rest asynchronously.
{%- comment -%}
Step 1: Inline critical CSS directly in the head.
Generate your critical CSS using a tool like our
Critical CSS Generator at /tools/critical-css-generator/
Then paste it into a snippet: snippets/critical-css.liquid
{%- endcomment -%}
<style>
{% render 'critical-css' %}
</style>
{%- comment -%}
Step 2: Load full stylesheet asynchronously using the media trick.
The browser treats media="print" as non-render-blocking,
then onload switches it to media="all" so styles apply.
{%- endcomment -%}
<link rel="stylesheet"
href="{{ 'base.css' | asset_url }}"
media="print"
onload="this.media='all'">
<noscript>
<link rel="stylesheet" href="{{ 'base.css' | asset_url }}">
</noscript>Alternatively, Shopify provides the inline_asset_content Liquid filter which can inline CSS from your asset files directly, eliminating the need for a separate snippet:
<style>{{ 'critical.css' | asset_url | inline_asset_content }}</style>Generating critical CSS correctly requires analyzing every template. I recommend using a critical CSS generator tool — it extracts exactly the CSS rules needed for above-the-fold content on each page type. Getting this wrong (missing a rule for your hero section, for example) causes a flash of unstyled content that's worse than no optimization at all.
Parser-blocking scripts are the second-biggest performance killer after render-blocking CSS. Shopify's official guidance is clear: your minified JS bundle should be 16KB or less, and everything else should be deferred.
In theme.liquid, find your <script> tags and add defer:
{%- comment -%}
WRONG — blocks DOM parsing:
{{ 'theme.js' | asset_url | script_tag }}
RIGHT — deferred loading:
{%- endcomment -%}
<script src="{{ 'theme.js' | asset_url }}" defer></script>
{%- comment -%}
For third-party scripts (analytics, chat widgets, etc.),
load them after the page is interactive:
{%- endcomment -%}
<script>
// Load non-essential scripts after user interaction
function loadDeferredScripts() {
// Example: chat widget, analytics, etc.
var scripts = [
'{{ "deferred-features.js" | asset_url }}'
];
scripts.forEach(function(src) {
var s = document.createElement('script');
s.src = src;
s.defer = true;
document.body.appendChild(s);
});
}
// Trigger on first user interaction
['click', 'scroll', 'keydown', 'touchstart'].forEach(function(evt) {
window.addEventListener(evt, function handler() {
loadDeferredScripts();
['click', 'scroll', 'keydown', 'touchstart'].forEach(function(e) {
window.removeEventListener(e, handler);
});
}, { once: true, passive: true });
});
</script>The interaction-based loading pattern is aggressive but effective. Chat widgets, review popups, and similar features don't need to load until the user actually does something on the page. On one store we tested, this pattern shaved 340ms off Time to Interactive — which was the difference between a "needs improvement" and "good" INP score in CrUX data.
When someone shares your product on Facebook, Twitter, or LinkedIn, OG (Open Graph) tags control what appears in the preview. Without them, social platforms guess — and they guess badly. I've seen product shares show up with the store's favicon as the image and the checkout page title as the description.
Dawn includes a social-meta-tags.liquid snippet, but it's often minimal. Here's a comprehensive version. Create or update snippets/social-meta-tags.liquid:
{%- liquid
assign og_title = page_title | default: shop.name
assign og_description = page_description | default: shop.description | strip_html | truncate: 200
assign og_url = canonical_url | default: request.origin | append: request.path
assign og_type = 'website'
assign og_image = ''
-%}
{%- if template.name == 'product' -%}
{%- assign og_type = 'product' -%}
{%- if product.featured_image -%}
{%- assign og_image = product.featured_image | image_url: width: 1200, height: 630 -%}
{%- endif -%}
{%- elsif template.name == 'article' -%}
{%- assign og_type = 'article' -%}
{%- if article.image -%}
{%- assign og_image = article.image | image_url: width: 1200, height: 630 -%}
{%- endif -%}
{%- elsif template.name == 'collection' -%}
{%- if collection.image -%}
{%- assign og_image = collection.image | image_url: width: 1200, height: 630 -%}
{%- endif -%}
{%- endif -%}
{%- if og_image == blank and shop.brand.cover_image -%}
{%- assign og_image = shop.brand.cover_image | image_url: width: 1200, height: 630 -%}
{%- endif -%}
<!-- Open Graph -->
<meta property="og:site_name" content="{{ shop.name }}">
<meta property="og:title" content="{{ og_title }}">
<meta property="og:description" content="{{ og_description }}">
<meta property="og:url" content="{{ og_url }}">
<meta property="og:type" content="{{ og_type }}">
{%- if og_image != blank -%}
<meta property="og:image" content="{{ og_image }}">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
{%- endif -%}
{%- if template.name == 'product' -%}
<meta property="product:price:amount" content="{{ product.price | money_without_currency }}">
<meta property="product:price:currency" content="{{ cart.currency.iso_code }}">
{%- endif -%}
<!-- Twitter Card -->
<meta name="twitter:card" content="summary_large_image">
<meta name="twitter:title" content="{{ og_title }}">
<meta name="twitter:description" content="{{ og_description }}">
{%- if og_image != blank -%}
<meta name="twitter:image" content="{{ og_image }}">
{%- endif -%}Include it in theme.liquid with {% render 'social-meta-tags' %} inside <head>. The 1200x630 image dimensions are optimized for both Facebook and Twitter/X's large card format.
If you sell in multiple countries or languages, hreflang tags tell Google which version of a page to show to which audience. Without them, your French store might appear in German search results — and I've seen exactly this happen to a client who was getting support tickets in the wrong language for months before they realized the cause.
Shopify Markets automatically generates hreflang tags for international domains and subfolders. But if you need custom control — or you're using a translation app — add this to theme.liquid's <head>:
{%- if request.locale and localization.available_languages.size > 1 -%}
{%- for locale in localization.available_languages -%}
{%- if locale.primary -%}
{%- assign locale_root = shop.url -%}
{%- else -%}
{%- assign locale_root = shop.url | append: '/' | append: locale.iso_code -%}
{%- endif -%}
<link rel="alternate"
hreflang="{{ locale.iso_code }}"
href="{{ locale_root }}{{ request.path }}">
{%- endfor -%}
{%- comment -%} x-default points to your primary language {%- endcomment -%}
<link rel="alternate"
hreflang="x-default"
href="{{ shop.url }}{{ request.path }}">
{%- endif -%}The x-default tag is critical — it tells Google which version to show when none of the specified languages match the user's preference. Always point it to your primary market.
Native lazy loading is now supported by 92% of browsers. Shopify's image_tag Liquid filter handles this automatically — images past the first three sections get loading="lazy" by default.
But you need to make sure you're not lazy loading above-the-fold images, which is a common mistake that actually hurts LCP. I audited a store last month that had loading="lazy" on their hero banner — it was adding 800ms to their LCP because the browser deprioritized the most important image on the page:
{%- comment -%}
Hero image — above the fold, NEVER lazy load.
Use loading: 'eager' and fetchpriority: 'high' to prioritize it.
{%- endcomment -%}
{{ section.settings.hero_image
| image_url: width: 1920
| image_tag:
loading: 'eager',
fetchpriority: 'high',
sizes: '100vw',
widths: '375, 750, 1100, 1500, 1920'
}}
{%- comment -%}
Product images below the fold — let Shopify's default lazy loading work.
Don't set loading attribute; Shopify handles it via section.index.
{%- endcomment -%}
{{ product.featured_image
| image_url: width: 800
| image_tag:
sizes: '(min-width: 750px) 50vw, 100vw',
widths: '375, 750, 800'
}}The fetchpriority: 'high' attribute on your LCP image is a newer addition that tells the browser to prioritize this image over other resources. Combined with not lazy loading it, this is the single most impactful thing you can do for your LCP score.
You've made the changes. Now verify they actually work. (I've seen developers skip this step and discover three months later that their schema was invalid the entire time.)
Step 1: Validate structured data. Go to Google's Rich Results Test and enter your product URL. Every schema type you added should appear with a green checkmark. Common errors: missing commas in JSON-LD arrays, unescaped quotes in product descriptions, and invalid image URLs.
Step 2: Check canonical tags. View page source (Ctrl+U) and search for "canonical". You should see exactly one canonical tag per page. If you see two, your theme was already adding one — remove the duplicate.
Step 3: Run Lighthouse. Open Chrome DevTools → Lighthouse → check Performance and SEO → Generate Report. Compare your scores before and after. Keep screenshots — you'll want the before/after comparison when a client asks what you did.
Step 4: Test social previews. Use Facebook's Sharing Debugger and Twitter's Card Validator to preview how your product pages look when shared.
Common mistakes that will bite you:
Here's what you can realistically expect from each optimization, based on audits I've run on Dawn-based stores:
| Optimization | Expected LCP Change | Expected CLS Change | Lighthouse Points |
|---|---|---|---|
| Font preloading | -300ms to -1.2s | No change | +3 to +8 |
| Critical CSS inlining | -200ms to -800ms | -0.02 to -0.05 | +5 to +15 |
| Defer non-critical JS | -100ms to -500ms | No change | +3 to +10 |
| Image lazy loading (correct) | -100ms to -400ms | Slight improvement | +2 to +5 |
| Schema markup (all types) | No change | No change | +2 to +5 (SEO score) |
| Canonical + hreflang | No change | No change | +1 to +3 (SEO score) |
| Combined total | -0.7s to -2.9s | -0.02 to -0.05 | +15 to +35 |
These numbers vary significantly based on your starting point. A store already scoring 85+ on Lighthouse will see smaller gains than one scoring 55. The font preloading and critical CSS changes consistently deliver the biggest improvements — if you're short on time, start with those two.
If you're editing the theme code directly — no. Theme updates will overwrite your changes. That's why I recommend using snippets (json-ld-product.liquid, social-meta-tags.liquid, etc.) whenever possible. Snippets survive some updates. For maximum safety, document every change you make and re-apply after updates, or use a version control workflow with Shopify CLI.
Yes, apps like JSON-LD for SEO and Smart SEO handle schema markup without code changes. The tradeoff: apps add JavaScript overhead (ironic for performance optimization), cost $5-20/month, and give you less control. For font preloading and critical CSS, there's no substitute for code-level changes.
The schema markup, OG tags, and hreflang code work with any Shopify theme. Font preloading syntax may differ — check your theme's settings_schema.json for the correct font variable names. Critical CSS is theme-specific by definition. The Liquid code patterns are universal across Online Store 2.0 themes.
Use Google's Rich Results Test (search.google.com/test/rich-results) for individual URLs. For site-wide validation, check Google Search Console → Enhancements. It can take 2-4 weeks for Google to process new structured data and show results in the Enhancements report.
defer and async on script tags?defer downloads the script in parallel but waits to execute it until the HTML is fully parsed. async downloads in parallel and executes immediately when ready — which can interrupt HTML parsing. For theme scripts, always use defer. Use async only for truly independent scripts like analytics that don't interact with the DOM.
These 10 optimizations cover the highest-impact changes you can make to theme.liquid. But SEO is more than code. Your product descriptions, internal linking, image alt texts, and content strategy matter just as much.
If you want to go deeper:
Good breakdown on theme.liquid controlling headers/footers, meta tags and schema. In my 9 years managing Shopify CRO for mid‑market retailers the biggest wins came from pruning app‑injected JS and using Shopify Theme Inspector + Lighthouse to target third‑party scripts (we cut TBT ~40%) — audit apps before broad theme edits, happy to connect and share the checklist.
100% — app JS is the low‑hanging fruit. Pro tip: gate non‑essential third‑party scripts behind consent + load them via async/defer or dynamic import; inline critical CSS & use native lazy‑loading. I’ve cut ~30% TBT doing that + swapping heavy tag managers for lightweight beacons. Run WebPageTest’s third‑party breakdown + Lighthouse + PerformanceObserver for long‑tasks. DM me — happy to swap checklists. #CoreWebVitals
tbh theme.liquid's overrated — nuked a bunch of app scripts (not meta tag edits) and speed jumped ngl.
imo article's right that theme.liquid holds meta tags and internal links, but don't shove global JSON‑LD into theme.liquid for big catalogs — it bloats every page; inject per‑product JSON‑LD in product templates, lazy‑load noncritical scripts and preload fonts instead, ran that on a 5k SKU store and dropped mobile LCP by ~1.8s, correct me if I'm wrong but try Lighthouse CI + Theme Inspector.
no credit card required