DEV Community: Smart Calculators

Two frame-cap rules differ by 3 fps at 144 Hz. By 540 Hz it's 72.

Smart Calculators — Wed, 16 Sep 2026 10:20:34 +0000

Every frame-rate cap calculator asks for one number: how far below your refresh rate to cap. Almost none
of them tell you there are two different ways to compute "how far below," and the two stay within a few fps
of each other only over the Hz range the rule of thumb was actually coined for.

I ran into this modelling the cap logic behind a frame-cap tool, and it turned into a small case study in
what happens when a rule of thumb gets extrapolated past the range it was fit on.

Two rules for the same number

Rule one: cap at Hz - 3. It's the standard advice — G-SYNC's own documentation states it as a minimum,
not a target — and it's a constant subtracted from the refresh rate regardless of what that refresh rate
is.

Rule two: cap so the frame interval is a fixed amount longer than the refresh period, rather than a
fixed number of frames short of it. NVIDIA publishes five Reflex-with-G-SYNC caps as a small lookup table:
59, 97, 116, 138, 224 fps at 60, 100, 120, 144, 240 Hz. There's no formula printed next to that table.
Reverse-fitting a constant against all five lands on:

// pseudocode, not the actual engine — illustrates the fit, not the implementation
cap = round(1000 / (1000 / hz + 0.30))

At a 0.30 ms margin this reproduces all five published values exactly. That's enough evidence that the
real rule is a fixed frametime margin, not a fixed fps margin — but the 0.30 ms itself isn't a documented
NVIDIA spec. It's the constant that happens to make five published numbers line up.

Where the two rules split

At 144 Hz the two rules are close. Hz - 3 caps at 141 fps, leaving a 0.1478 ms cushion per frame. The
frametime rule, run through the same 0.30 ms constant, caps at 138 fps — a 3-fps gap, small enough that
most guides don't bother distinguishing the two.

Push the refresh rate up and the fixed-fps rule quietly runs out of margin. At 480 Hz, Hz - 3 caps at
477 fps, which leaves a cushion of only 0.0131 ms per frame — about 11 times thinner than the 0.1478 ms
cushion it left at 144 Hz, for the exact same "minus 3" rule. The frametime rule, still holding its 0.30
ms margin, caps at 420 fps instead — 57 fps lower, because holding the margin fixed is exactly what
makes the cap move.

By 540 Hz the split stops being subtle. Hz - 3 caps at 537 fps — a 0.0103 ms cushion, thin enough that
one dropped frame from a background process eats the entire margin. The frametime rule caps at 465 fps,
protecting the same 0.30 ms it held at every other point on the ladder. Same monitor, same stated
intent ("leave a safety margin"), and a 72-fps disagreement on where the cap should sit.

Worth noting which rule is stricter, because it flips. At 60 Hz, Hz - 3 caps at 57 while the frametime
rule caps at 59 — down there the fps rule is the more conservative of the two. They cross at 100 Hz,
where both land on 97, and from there the ordering inverts and keeps widening.

Neither rule is wrong. Hz - 3 is a fine approximation exactly where it was coined — 60-144 Hz panels —
and it breaks down by construction once individual frames get short enough that three of them stop being
a meaningful buffer.

The other place a constant hides a formula: LFC dead bands

The same "there's a formula behind the lookup table" pattern shows up in Low Framerate Compensation
windows. A VRR panel with floor f and ceiling c repeats frames at integer multiples to stay inside the
window, but not every frame rate below the floor has a legal multiple to repeat into. The gap under
multiplier k is the open interval (c/(k+1), f/k), and it's non-empty exactly when c < 2f.

Run that closed form on a 48-60 Hz window — a spec you'll find on a fair number of VRR OLED panels — and
it produces exactly three dead bands: 30-48 fps, 20-24 fps, and 15-16 fps. A frame rate inside one of those
bands can't be cleanly doubled or tripled into the window, so it either tears or judders. The count of
bands isn't a lookup value; it falls straight out of the inequality above once you plug in the floor and
ceiling.

Built this into a calculator

I put both of these — the two cap rules and the LFC dead-band ladder — into a small calculator:
https://smart-calculators.net/en-US/tools/refresh-rate-calculator. It runs the formulas above against
your own Hz, floor and margin instead of a fixed five-row table, so you can see exactly how far apart your
panel's two cap rules sit, and which of them is the strict one at your Hz.

What it doesn't model: display persistence and motion blur are a separate calculation in the same tool,
and the cap-rule math above assumes a fixed refresh period, no adaptive-sync jitter, and no compositor
overhead beyond the limiter's own frame delay (RTSS and driver-level limiters add one and two frames of
their own). Those are real costs. They're just not folded into the -3-vs-0.30ms comparison above.

Your rent-vs-buy break-even is two different numbers and nobody tells you which one you're seeing

Smart Calculators — Mon, 14 Sep 2026 18:58:05 +0000

Every rent-vs-buy calculator prints a break-even year. Almost none of them tell you it's underdetermined.

I ran into this building the model behind a rent-vs-buy tool, and it's a good example of a modelling
decision that's invisible in the output but changes the answer by years.

The setup

Standard inputs: $450,000 home, 20% down ($90,000), 6.66% mortgage rate, $2,400/month rent, $9,000
closing costs, 5%/year assumed investment return. Nothing exotic. The question the calculator is
supposed to answer is: at what year does owning become cheaper than renting?

Here's the part that doesn't show up in the UI. Renting doesn't require $90,000 up front. That money
either goes into a down payment, or it stays invested and keeps compounding. Whether you charge the
buying scenario for that forgone return is a modelling choice, not a fact about the mortgage.

Same inputs, same math library, two defensible break-evens:

// pseudocode, not the actual engine — illustrates the branch, not the implementation
function breakEvenYear(inputs, chargeOpportunityCost) {
  let ownerCost = inputs.downPayment + inputs.closingCosts;
  let renterCost = 0;
  for (year of horizon) {
    ownerCost += mortgagePayment + propertyTax + maintenance - homeEquityGained;
    renterCost += annualRent;
    if (chargeOpportunityCost) {
      // the buyer sank this cash into the house; the renter's copy of it stays
      // in an index fund compounding at investmentReturn, so the forgone return
      // is a cost carried by the BUYER
      ownerCost += (downPayment + closingCosts) * ((1 + investmentReturn) ** year - 1);
    }
    if (ownerCost < renterCost) return year;
  }
}

With the opportunity cost charged, break-even lands at year 8. With it switched off — treating the
$90,000 as gone the moment it's spent, on both sides — break-even is 4 years 3 months. Same house,
same rate, same rent. The gap between the two answers is just what $99,000 would have earned at 5%
a year, compounded, and that's a big enough gap that "when does buying win" depends entirely on which
branch the tool took silently.

Where this actually bites

It's not just an academic gap between the two break-even numbers. At a 7-year horizon in this same
scenario, the buyer's projected net worth comes out to $193,878 and the renter's to $200,559 — the
renter is still ahead. But the break-even card (computed with opportunity cost charged) says the
crossover happens in year 8. Someone reading only the headline break-even number at year 7 would
conclude they're one year from the finish line, when the net-worth comparison for their actual horizon
already has them on the wrong side of it. The two numbers are answering different questions — "when do
the running totals cross" versus "who's ahead at my horizon" — and they can legitimately disagree by a
full year around the crossing point.

A second underdetermined branch: the deduction

Most of these calculators also assume the buyer itemizes and gets the full value of mortgage-interest
and property-tax deductions. In this scenario, year-one deductible interest is $23,858 and property tax
is $4,116 — $27,974 itemizable. The 2026 standard deduction for married filing jointly is $32,200 (IRS
inflation-adjusted figures for tax year 2026). $27,974 loses. A model that doesn't check this gives the
buyer a tax break they wouldn't actually get.

I checked how a few well-known tools handle both of these branches:

Calculator.net's default case prints a single line — "Buying is cheaper if you stay for 4.9 years or longer" — no visible branch.
Zillow publishes one breakeven horizon, no second scenario.
Redfin skips a break-even year entirely and compares four cost categories instead.
NerdWallet's stated methodology assumes itemizing: "We assume buyers can save on taxes by itemizing federal tax deductions for both property tax and mortgage interest," with no gate against the standard deduction.
michaelbluejay.com's calculator does gate the deduction against the standard deduction — credit where due — though its defaults are 2020-era ($12,400 standard deduction, $1,000,000 mortgage-interest cap, the latter superseded by the $750,000 cap for loans taken after 2017). The fields are editable, so that's a stale default rather than a missing branch.

None of this makes any of these tools wrong, exactly. It makes the break-even year a much softer
number than its single-line presentation suggests.

What I don't model either

Being honest about the limits: every rate in this model is held constant for the whole horizon, so
there's no sequence-of-returns risk — a market crash in year 2 versus year 9 produces the identical
output, which isn't how markets work. It's US federal income tax only, no state tax, no AMT, no phase-
down of the SALT cap (which the model holds at the 2026 $40,400 figure for the entire horizon, even
though the statute drops it back to $10,000 starting in 2030). No utilities, no moving costs, no
commute changes, no rent control. And it assumes you sell at the end of the horizon and eat the full
selling cost, which isn't everyone's plan.

The honest way to use a model like this isn't to trust either single number. It's to run it with the
opportunity-cost branch on and off and look at the spread — if your actual decision only makes sense
under one of the two assumptions, that's the thing worth knowing before year 8 arrives.

If you want to poke at the two branches yourself with your own numbers, the calculator this came out of
is at https://smart-calculators.net/en-US/tools/rent-vs-buy — it shows both break-even years side by
side by default rather than picking one for you.

Shipping 30 locales at once taught me what Google actually tracks in hreflang

Smart Calculators — Thu, 16 Apr 2026 17:14:14 +0000

The conventional wisdom on multi-locale rollouts is "ship incrementally." I ignored it. I had a static Next.js site, a batch of localised content that had passed review, and a clean hreflang implementation. Rolling out 20 new locales in a single release felt like a low-risk operation.

It wasn't. The search-visibility dip showed up within days — not because anything was technically broken, but because I had underestimated how much of hreflang's behaviour is a trust model, not a structural one.

This post is what I wish someone had told me before that deploy.

Hreflang is a trust declaration, not a translation directive

If you have five English variants (en-US, en-GB, en-AU, en-CA, en-IN) and five Spanish variants (es-ES, es-MX, es-CO, es-AR, es-CL), Google does not just read the hreflang cluster and serve each region the right version.

It evaluates whether the content actually differs enough per variant to justify the cluster. If the pages look like identical English copy with slightly different URLs, or identical Spanish copy with slightly different disclaimers, the cluster can look like duplication with extra steps.

The fix was not more locales. The fix was fewer locales done more thoroughly.

A multi-locale page is not "done" when the text is translated

Translation is the cheapest part. Credibility is the expensive part.

A French user arriving at /fr-FR/tools/mortgage expects French-language examples, French tax treatment, French-currency defaults, and a disclaimer that reads like a French person wrote it. If any of those are missing, the page reads as a translated English page that happens to live at a French URL — and both Google and the user can smell the difference.

The lesson I internalised: shipping a locale means shipping the full locale-specific context, not just the translated UI strings.

Schema choices matter more than I expected

I had WebApplication JSON-LD on every calculator page. On paper, that was correct — these pages are interactive web applications.

In the SERP, what Google did with that signal was not what I wanted. The snippet treatment started looking more like a software-product card and less like a rich tool result. For a utility page where users need to see the actual calculator content to decide to click, that swap hurt click-through before anything in the algorithm could evaluate whether the content was good.

I switched to HowTo-style schemas that describe the calculation method, and the snippet treatment moved back toward something more useful.

The hreflang bit that still holds up

Most of the chaos came from things I had to unlearn. One piece did not need unlearning: the sitemap-time alternate generation. It is boring by design — and boring is exactly what hreflang clusters reward.

function buildAlternates(path) {
  const alternates = [];
  for (const locale of locales) {
    alternates.push({ locale, href: `${BASE_URL}/${locale}${path}` });
  }
  alternates.push({ locale: "x-default", href: `${BASE_URL}/${defaultLocale}${path}` });
  return alternates;
}

Two things worth stealing from this shape:

Every locale gets a fully-qualified URL including the hostname. Relative hrefs work locally but can be misinterpreted by crawlers that hit the sitemap from a different origin.
x-default always points at the default-locale version of the same path. It never changes per release. Moving x-default around is one of the fastest ways to lose Google's patience with your cluster.

Anything fancier than this — per-locale path rewrites, canonical hopping, conditional redirects — usually makes things worse under pressure.

The takeaways

Don't stack locale rollouts. One or two locales per release, with time between them, keeps the cluster interpretable.
Localise context, not strings. The page has to read like it was made for that market, not translated for it.
Audit your JSON-LD. The wrong schema type can quietly change how your page appears in the SERP long before any content evaluation.
Keep x-default boring. Stable canonical fallback, never moved.

I build smart-calculators.net in my spare time — a multi-locale static calculator platform currently running on the lessons above. If you are about to ship a big i18n rollout, I hope this saves you a couple of weeks of Search Console anxiety.