How Magic Square Fixed Core Web Vitals in 14 Days and Lifted Organic Traffic

Client context

Magic Square is a Web3 app store and discovery platform. Users browse curated dApps across DeFi, NFT, gaming and infrastructure categories, with security ratings, audit info and direct connect-and-use flows for each listed app. The team had built genuine product differentiation around the security review process: every listed app had been audited, insurance-backed and rated.

The site was a Next.js application with about 800 indexable pages: category pages, individual app listings, security review pages, blog content and the help center. The product surface was solid. The engineering team was strong. The site loaded slowly enough that none of that mattered for SEO.

Magic Square came to us specifically about Core Web Vitals because they'd been monitoring their PageSpeed Insights scores and watching them stay red despite multiple optimization attempts. Lighthouse audits had been run, fixes had been deployed and the field data (CrUX) kept showing INP around 380ms and LCP around 2.8s on mobile. Both red. Both well into territory where Google's algorithm was actively demoting.

The team had also been wondering why their AI engine citation rate was lower than they'd expect for a curation-and-review platform. The kind of site AI engines should love (structured data about apps, security ratings, comparisons) was getting cited at maybe a third of the rate similar sites were achieving.

The problem

The CWV problem broke down into three primary contributors.

First, the wallet SDK situation. Magic Square uses RainbowKit and wagmi to power the connect-and-use flows on each app listing. The SDK was being initialized on every page mount including marketing pages, category pages, blog posts, the help center. About 250KB of JavaScript loading on every page even when the user had no intent to connect a wallet. This was costing 200-300ms of TBT (Total Blocking Time) which translated directly to INP scores.

Second, the IPFS image issue. Many of the apps listed on Magic Square use IPFS-hosted artwork for their logos, banners and screenshot galleries. The site was rendering these via direct IPFS gateway URLs. Public IPFS gateways are unreliable for SEO crawlers and slow for end users. Image LCP was getting hammered by IPFS gateway latency; og:image was failing to render in social previews about 40% of the time.

Third, the homepage ticker. Magic Square's homepage shows a live-updating ticker with featured apps, security alerts and category highlights. The ticker was loading and initializing immediately on page mount with about 80KB of JavaScript and a WebSocket connection. None of this was visible above the fold. None of it was needed for first paint. But it was blocking the main thread during the critical INP window.

On the schema side, Magic Square was emitting generic Article schema across all listing pages. Apps like Aave should have been Product or FinancialProduct. NFT marketplaces like OpenSea should have been Service. DeFi positions and yield products should have been FinancialProduct with specific properties. Generic Article was wrong for all of them.

The audit

Two-week audit. The CWV findings were the clear top priority because they were Google ranking factors, not just AI engine signals.

We confirmed the wallet SDK was the largest single contributor to TBT and INP. Bundle analyzer showed the SDK and its dependencies accounting for about 60% of the initial JavaScript payload on marketing pages. The fix was straightforward: lazy-load the SDK behind a user action trigger.

The IPFS issue was diagnosed via a Performance trace on real listing pages. Image fetches from public IPFS gateways were taking 5-8 seconds in the worst cases. CDN caching with origin-pull from a reliable pinning service (Pinata) was the right pattern.

The ticker issue was the smallest CWV contributor but still material. Deferring its initialization until after first paint, plus moving the WebSocket connection to a setTimeout-deferred bootstrap, would clear the remaining TBT.

The schema issue was a separate work stream. Mapping each app type to the correct schema (Product for NFT items, FinancialProduct for DeFi positions, Service for marketplaces, Cryptocurrency for token launches) would enable both rich result eligibility and AI engine citation lifts. Stacking FAQPage with Speakable on top would amplify the AEO impact.

We sequenced the work CWV-first, schema-second. The CWV fixes were ranking-critical and could ship in days. The schema work needed more design (which schema for which app type) and would benefit from a faster site as the foundation.

The work

Results

The CWV work shipped in 14 days from kickoff. Within that window, both INP and LCP moved from red to green at the 75th percentile in PageSpeed Insights field data.

Organic traffic lifted by approximately 60% in the 60 days following CWV deployment. The lift was concentrated on long-tail queries (specific app names plus modifiers) which had been particularly impacted by the slow page experience.

AI Overview citations increased substantially after the schema work shipped. ChatGPT and Perplexity both started citing Magic Square on app discovery and security queries where they had previously cited only the underlying apps directly.

The /security/ section drove an outsized share of conversion lift. Conversion rate (defined as the user clicking through to actually use a listed app) on security-content pages came in 23% above the site average. Users who landed on a security review page were pre-qualified and converted better.

5 tactical lessons you can apply

AB's takeaway

Magic Square was the cleanest engagement of the four because the problems were tactical and the fixes were well-understood. The lazy-load wallet SDK pattern, the IPFS CDN caching pattern and the schema split pattern are all things we've since codified into Crawlux audit modules.

The time-to-impact was the standout. Most SEO work has a 60-90 day measurement window. The CWV work showed lab data improvement immediately and field data improvement within the 28-day CrUX window. The team could see the change in their own measurements within two weeks.

The schema work followed a longer timeline (60-90 days for ranking impact) but the AEO citation lift showed up within three weeks. AI engines re-crawl frequently. Schema improvements show up in citation rates much faster than they show up in Google rankings.

What we'd do differently

One thing.

We'd have built the /security/ content hub before the schema work rather than alongside it. The schema work assumed a destination existed for the security FAQ entries. The destination got built in parallel with the schema. This was workable but it meant the schema went live with some FAQ entries pointing at sections of the security hub that weren't fully populated yet. Sequencing the hub first would have meant cleaner schema launches and a more polished initial experience.

Beyond that, the engagement ran clean. The technical fixes were textbook applications of patterns that work. The team executed quickly. The results were measurable.

Run a free Crawlux audit on your site

The audit identifies which schema, technical and AEO issues are blocking your rankings. Same diagnostic framework we used at Magic Square.