
Key takeaways
- CoinStats, a cryptocurrency price and portfolio tracking site, had poor Core Web Vitals and high bounce rates, mostly from images slowing Largest Contentful Paint.
- One fix the team names is replacing Base64 images embedded in the HTML document with standard img src URLs, which had been increasing page size.
- CoinStats says it updated around 15,000 pages, and that using img src URLs throughout the site cut the HTML's download size in half.
- DebugBear's case study quotes CoinStats saying "Good URLs" and their impressions have increased 3x since implementation.
- The case study does not publish a timeframe, exact before and after scores, or specific URLs, so treat the multiplier as directional, not a precise rate.
DebugBear, a Core Web Vitals monitoring vendor, publishes a small library of named customer case studies. One of them covers CoinStats, a cryptocurrency price and portfolio tracking site, and walks through a single root cause, a single fix, and a reported before-and-after change in search performance. Unlike the Rakuten and Vodafone A/B tests Google itself ran, this one is a vendor-published customer story rather than a controlled experiment, and it is worth reading with that distinction in mind.
What was broken
DebugBear’s write-up quotes CoinStats saying Search Console showed it “doing poorly on Google’s Core Web Vitals,” with high bounce rates, and that it mostly had images causing a slow Largest Contentful Paint. As one example, the team says it “used to include a lot of Base64 images in the HTML document” instead of linking to them through a normal img src URL, and that DebugBear helped it notice this was increasing the page size.
What CoinStats changed
The example fix was narrow: replace inline Base64 images with conventional img src URLs. DebugBear’s case study quotes CoinStats’ Senior SEO Specialist, Rafayel Begoyan, saying “we’ve updated around 15,000 pages and saw some nice gains from it,” and that using img src URLs throughout the site means the download size of the HTML “has been cut in half.” He reports the outcome in one sentence: “Good URLs” and their impressions “have increased 3x since implementation.”
Why this is directional
DebugBear’s page does not publish a start date, an end date, the raw impression counts behind the 3x figure, or the actual before-and-after Core Web Vitals scores for the pages involved. It is a vendor case study built to sell a monitoring product, told from the customer’s side, with one named quote and no independently reproducible numbers. That does not make the claim false, but it does mean the “3x” figure should be cited as CoinStats’ own reported comparison, not as a rate any site removing Base64 images should expect to match.
The evidence
- Subject
- CoinStats' Core Web Vitals fix and its organic search impact
- Timeframe
- not disclosed by DebugBear
- Verified
- Yes, against first-party data
| Metric | Before | After |
|---|---|---|
| Good URLs, before vs after the changes | 1x | 3x |
| Impressions of Good URLs, before vs after the changes | 1x | 3x |
| HTML download size, before vs after using img src URLs | 100% | 50% |
| Pages CoinStats says it updated | 0pages | 15000pages |
Sources
- 1.How CoinStats Grew Organic Traffic With Better Core Web Vitals - DebugBearPrimary
Common questions
What exactly was wrong with CoinStats' pages?
According to DebugBear's case study, Search Console showed CoinStats doing poorly on Core Web Vitals, with high bounce rates. The team says images mostly caused a slow Largest Contentful Paint, and names Base64 images embedded in the HTML as one example.
How many pages did CoinStats actually change?
CoinStats' Senior SEO Specialist Rafayel Begoyan says "we've updated around 15,000 pages." Separately, he says using img src URLs instead of inline Base64 images cut the HTML's download size in half. The case study does not link the two figures explicitly.
Does "3x" mean search traffic tripled?
No. The case study says "Good URLs" and their impressions "have increased 3x since implementation." That covers impressions of Good URLs, not clicks or all search traffic. DebugBear publishes no dates or raw numbers, so treat it as CoinStats' own reported comparison.
About the author

Founder, UpgradIQ FZC LLC
Adam Hafez works on technical SEO and search measurement: how pages get crawled, indexed, ranked and now quoted by answer engines. He founded UpgradIQ, which reads Google Search Console and GA4 to tie ranking movement back to the changes that caused it. He publishes what the data supports and states the limits of it.
- Technical SEO
- Search Console and GA4
- Answer engine optimization
- Structured data
The briefing
Only what actually changed in search, delivered in full by RSS, Atom or JSON feed.
FollowRelated reading
Median home page weight 2025: 2.86 MB desktop, 2.56 MB mobile
The 2025 Web Almanac puts the median home page at 2.86 MB on desktop and 2.56 MB on mobile, with images and JavaScript the two largest parts.
Image lazy loading and width/height checker
Image lazy loading checker: paste HTML to test every img tag for width and height, lazy loading on the likely LCP image. Free, runs in your browser.
Page weight and rankings: what the Backlinko study actually found
Backlinko and Ahrefs analyzed 11.8 million search results and found no correlation between page HTML size and Google rankings.
INP in 2025: 77% of mobile sites pass, but the top 1,000 lag at 63%
The 2025 Web Almanac's INP data: 77% of mobile sites have good INP, popular sites trail at 63%, and mobile home pages beat inner pages 80% to 69%.



