DEV Community: Beksultan Sagnaev

How We Turned a High-Traffic News Site's Core Web Vitals from Red to Green

Beksultan Sagnaev — Tue, 14 Jul 2026 15:19:21 +0000

The setup: a news site where every millisecond is public

Kapital.kz is one of Kazakhstan's high-traffic business and finance news portals, built on Next.js. Unlike a typical marketing site, a news portal has a brutal constraint: every page is a landing page. Every article is someone's entry point from Google, and Google's Core Web Vitals directly influence how well those articles rank. A slow, janky article page doesn't just annoy readers — it actively pushes the site down in search results.

When I joined the team at Musan Group, all three Core Web Vitals metrics — LCP, INP, and CLS — were sitting in the red zone on finance.kapital.kz. For context, Google's thresholds put "poor" LCP above 4.0s (versus "good" at 2.5s or under), "poor" INP above 500ms (versus 200ms or under), and "poor" CLS above 0.25 (versus 0.1 or under) — that's the red-to-green gap we were closing. Here's what that actually meant in practice, and what it took to fix each one.

LCP: the hero image problem

Largest Contentful Paint measures how long it takes for the biggest visible element — usually the hero image or headline — to render. On a news site, that's almost always the article's cover image.
The fixes here were less about clever tricks and more about removing waste: cutting unnecessary client-side work that delayed the image request, and making sure the image itself wasn't fighting other resources for bandwidth on first load. Combined with general rendering path cleanup, this brought LCP on finance.kapital.kz down out of the red zone.

INP: the interaction that made the page feel broken

Interaction to Next Paint replaced FID as a Core Web Vital, and it measures something more honest: not just "did the first click register fast," but "does every interaction on this page feel instant, for the whole time the user is on it." A page can have great LCP and still feel broken if scrolling stutters or a click takes half a second to respond.

Two things were quietly wrecking INP on article pages:
Google Ads scripts loaded incorrectly. Ad scripts are notorious for blocking the main thread — if they're not loaded with the right strategy (deferred, lazy, or isolated from critical rendering work), every ad slot on the page becomes a tax on every single interaction, not just page load.

Heavy libraries sitting in the main bundle. Some dependencies had no business being loaded upfront on every article page. Moving them out of the initial JS bundle — loading them only when actually needed — freed up the main thread to actually respond to user input instead of parsing and executing code nobody was using yet. One concrete example: a heavy date/time-picker library used only on category-navigation pages was loading globally, on every single article page — including the ones that never used it. Swapping it for the lightest available alternative, with no visible UI trade-off, cut dead weight out of the main bundle entirely.

Between fixing the ad loading strategy and pulling heavy libraries out of the critical path, INP moved into the green zone.

CLS: the classic culprits — ads and infinite scroll

Cumulative Layout Shift measures visual stability — how much content jumps around as the page loads. For a news site, the two biggest offenders are almost always the same:

Ads without reserved space. When an ad slot doesn't have a fixed size reserved before the ad itself loads, the page content jumps down the moment the ad finally renders — classic CLS violation, and one of the most common on ad-supported sites specifically.

Infinite scroll done carelessly. As new articles load in below the fold, any miscalculation in how their height is estimated before the images finish loading causes the whole feed to jitter and shift under the reader's thumb. One visible symptom: the site's global footer would jump up and down every time a new batch of articles loaded, because the page's total height kept getting recalculated on the fly.

Fixing both — properly reserving space for ad units before they load, and correcting how infinite-scroll batches estimate their height before content is fully rendered — eliminated the layout shift almost entirely.

Finding the problems in the first place: BigQuery over guesswork

Here's the part that made the difference between guessing at fixes and actually targeting the right ones: instead of relying only on lab data (Lighthouse scores, which are a single synthetic run), the team pulled real user monitoring data through BigQuery — actual field data from actual readers, on actual devices and connections across Kazakhstan.

This matters because lab data lies by omission. A Lighthouse run on a fast office connection tells you nothing about what a reader on a mid-range Android phone over a spotty mobile connection in a smaller city actually experiences. BigQuery let us see the real distribution of LCP/INP/CLS across the actual user base, and — critically — segment it: which specific pages, which devices, which network conditions were dragging the aggregate numbers down. That turned "the site feels slow" into a ranked list of specific, fixable bottlenecks.

The other half of technical SEO: making Google understand the content, not just render it fast

Core Web Vitals is only one pillar. The other half of technical SEO for a news site is making sure search engines can correctly parse what an article actually is — and this is where structured data and AMP come in.

Updating schema.org JSON-LD for news articles matters more than it sounds like it should. Structured data is how Google knows "this is a NewsArticle, published on this date, by this author, about this topic" instead of just guessing from raw HTML. Getting the JSON-LD schema right and current directly affects whether an article is eligible for rich results in search — the difference between a plain blue link and one with a headline, image, and publish date attached in the results page.

Fixing broken AMP versions closed a gap that's easy to overlook: if a site publishes both a regular and an AMP version of each article, and the AMP version is broken or out of sync, search engines either serve a degraded experience or lose trust in the AMP feed altogether — quietly hurting visibility for the very pages meant to load fastest on mobile search.

Alongside this, cleaning up HTML validation issues and fixing production bugs in the news card UI closed out the more mundane but still SEO-relevant half of the work: broken markup and inconsistent card rendering both chip away at how reliably a page renders — and gets crawled — across different devices and bots.

The takeaway

None of these fixes were exotic. Reserve space for ads. Defer what doesn't need to run immediately. Get your structured data right. Use field data, not just lab scores, to know what to fix first. What made it work wasn't a single trick — it was treating Core Web Vitals as a measurement problem first (find the real bottleneck via BigQuery) and a discipline problem second (systematically closing each gap: rendering path, ad loading, layout stability, structured data, AMP).

For a site where every article is a search-engine entry point, that discipline is the difference between ranking and not.

I work as a full-stack developer based in Astana, Kazakhstan, focused on Next.js, technical SEO, and performance optimization for high-traffic products. If you're dealing with Core Web Vitals or technical SEO issues on your own site, I'd be glad to compare notes — reach me on Telegram or LinkedIn, or check out more of my work at beksnotfound.kz.

Building a React Native SDK Inside a Super-App with 800K Daily Users

Beksultan Sagnaev — Fri, 10 Jul 2026 15:15:24 +0000

The problem: an SDK is not an app

Most React Native tutorials teach you to build a standalone app. You control the root navigation, the splash screen, the lifecycle — everything. But what happens when your React Native code has to live inside someone else's native app, one you don't control and definitely can't crash?

That's the brief I got at Kwaaka: embed a restaurant-coupons module into Onay, a Kazakhstan-wide super-app with roughly 800,000 daily active users. Onay users needed to discover nearby restaurant discounts without installing a separate app — the coupon experience had to feel native to an app we never touched the codebase of.
I was the sole frontend developer on this: architecture, performance, and shipping were entirely on me, working closely with Kwaaka's backend team and Onay's iOS/Android engineers who wired the SDK into their production app.

Why React Native (and not native-native)

Kwaaka's whole product suite runs on React on the web. Choosing React Native meant the team could share mental models and logic between web and mobile without hiring separate iOS/Android frontend specialists. State management ran on Effector — again, for consistency with Kwaaka's web stack, plus it's well-documented and widely used across the CIS developer community. In my experience, Effector is a genuinely simpler and more modern state manager than old-guard Redux (or Redux Toolkit, for that matter) — no action types to name, no reducers to switch over, no selectors to memoize by hand. You just declare events and stores, and derive everything else from them. Less boilerplate, less ceremony, and the dependency graph between stores stays explicit instead of hiding behind connect() or useSelector. Farfetched sat on top of Effector to handle caching, retries, and stale-while-revalidate out of the box.

The constraint that shaped everything: an SDK has no root navigation, no lifecycle of its own, and cannot crash the host app. A single unhandled JS exception inside a normal React Native app just crashes that app. Inside an SDK, it would take down Onay itself, for 800K people.

Shipping fixes without App Store review

Native review cycles are slow, and coupon logic changes fast. So I built a custom over-the-air update system: the JS bundle gets built, pushed to Cloudflare R2, and picked up by the SDK on next launch — no App Store review, no native app update required.
The system runs on two tiers:

latest.json — checked roughly every 30 minutes for routine updates
critical.json — a lightweight signal file checked every ~5 minutes; it doesn't carry the fix itself, it just tells the SDK "go check latest.json right now"

Every bundle is verified with a SHA-256 hash before being applied. If the native SDK version changes, the cache invalidates automatically, so an old JS bundle never tries to call native APIs that no longer exist. A small CI/CD script handles the whole pipeline: build → upload to R2 → update manifests → invalidate CDN cache. One script run, and the fix reaches every user with zero store releases.
Bridging into a host app without asking users to log in again
Onay users are already authenticated in the native app. Rather than showing a login screen inside the SDK, I pull the JWT, coordinates, and language straight from the native layer via NativeModules. From the user's perspective, the coupon module just opens — no second login, no friction.

Getting there meant close coordination with Onay's iOS and Android teams: agreeing on the native bridge API, the SDK's lifecycle, deep-link handling, and how the modal should dismiss. Neither side changed their existing architecture — the SDK had to fit into Onay's existing flow, not the other way around.

The platform-specific glue: Swift and Kotlin

On iOS, the public API is a single line for the host app:

swiftCouponsSDK.present(from: viewController, token: jwt, onTokenRefresh: cb, onDismiss: cb)

Underneath, a singleton bridge manager caches the RCT bridge by token — same token, same bridge instance reused; new token, fresh bridge. The SDK ships as an XCFramework via Swift Package Manager.
One detail I'm particularly glad I built: a temporary override of RCTFatalHandler. If the SDK's JS throws something unhandled, instead of crashing the host app, the SDK swaps in its own fatal handler, shows an error screen with a "Close" button, and restores the original handler on dismiss. Without this, any JS bug becomes an Onay crash.

Android mirrors the same ideas with its own constraints — a warmUp(application, token) call pre-warms the bridge on a daemon thread (roughly 60-80MB RAM, non-blocking), and the token gets read from the launching Intent before super.onCreate() so the RN bridge has it ready before the first render.

Both platforms share the same token-refresh contract: on a 401 from the coupons backend, the SDK calls back into native code, waits up to 30 seconds for a fresh token, retries once, and closes itself if that also fails. The host app doesn't know any of this is happening — it just supplies a callback.

Debugging without a safety net

Being the only frontend developer on a project means there's no code review above you, no second opinion before you merge. That's not a comfort claim — it's a constraint that forces you to think two steps ahead, because a wrong architectural call has no one to catch it.

Two bugs stood out as genuinely instructive:

The re-rendering header. Swiping between coupons was reloading the restaurant page's entire header — hero image, logo, info block — on every swipe. The chain: switching a coupon updated localActiveCouponId, which caused renderListHeader to be recreated, which remounted the coupon slider pager, which reset initialScrollIndex back to the first slide. The fix was to memoize the static parts of the header so the JSX object stayed stable, and move the coupon detail sections out of the header component into the SectionList's own sections — so renderListHeader no longer depended on the active coupon at all.

The empty home screen. After switching location away from Almaty and back, the home page stayed blank. Farfetched was serving cached — and empty — data for anything under 30 seconds old, skipping the network call entirely. The fix: call refresh() instead of start() on coordinate changes, which deliberately bypasses the cache.

The coupon logic itself

This turned out to be one of the trickiest parts of the whole project. Six coupon types — percentage off, fixed amount, free gift, paid gift, 2-for-1, and X+Y bundles — each with its own combination of unlock conditions: minimum order value, minimum item count, presence of specific products, or a minimum number of unique line items. All of it validated client-side in real time.

A widget I'm fairly happy with, CouponThresholdHint, shows a live progress bar and exact copy for whatever's still missing ("add 2 more items" vs. "add 1500₸ more"), correctly declined for Russian grammar (1 item / 2 items / 5 items follow different noun cases). Once the condition is met, it flips into a success state with a different visual treatment.

Checkout runs double validation: client-side first (to block the button and explain the problem before any request goes out), then server-side (validateCouponCart) right before order creation — if the backend rejects it, the error surfaces directly in the payment sheet. For gift and bundle coupons, the frontend has to construct part of the payload itself: resolving which product is the "free" one from the coupon's conditions, calculating quantity, and injecting it into the cart items before submission.

Where it stands
The SDK is live in a test rollout in Almaty, with the first partner locations connected and a geo-based coupon feed keyed to the user's coordinates. The architecture was deliberately built so that adding a new city doesn't require any client-side changes. It supports Russian, Kazakh, and English, auto-detected from the JWT and switchable on the fly.

Distribution through Onay solved the hardest problem a new product usually faces: building an audience from zero. The 800K users were already there — the job was making sure the coupon experience felt like it belonged.

I work as a full-stack developer based in Astana, Kazakhstan, focused on React, React Native, and mobile SDK integrations. If you're dealing with a similar "embed our thing inside someone else's app" problem, I'd be glad to compare notes — reach me on Telegram, LinkedIn or check out more of my work at beksnotfound.kz.