DEV Community: ValueMarkers

ISR vs SSR vs CSR: Performance Lessons from Building a Financial Data App with Next.js 14

ValueMarkers — Wed, 25 Mar 2026 05:34:38 +0000

When you're serving stock data for 100,000+ companies across 73 exchanges, rendering strategy isn't academic - it's the difference between a fast app and an unusable one. Here's what we learned building a financial data platform with Next.js 14.

The Challenge

Our app serves fundamentally different types of pages:

Stock detail pages (/stock/[ticker]): 100,000+ pages, data changes every 6 hours
Screener page (/screener): Highly interactive, user-driven filters
Leaderboard (/leaderboard): Changes hourly, consumed by many users
Blog posts (/blog/[slug]): Rarely changes, needs SEO

Each page type demands a different rendering approach.

Our Rendering Matrix

Page	Strategy	Revalidate	Why
`/stock/[ticker]`	ISR	6 hours	100K pages, data changes daily
`/leaderboard`	ISR	1 hour	Changes frequently, many readers
`/blog/[slug]`	ISR (Sanity CMS)	1 hour	SEO-critical, CMS-driven
`/screener`	CSR	-	Highly interactive, user-specific
Auth pages	CSR	-	User-specific, no SEO need
`/` (home)	SSR + Islands	-	Mix of static and dynamic

ISR for Stock Pages: The 100K Page Problem

With 100,000+ stocks, we can't pre-render everything at build time. ISR with on-demand revalidation is the solution:

// app/stock/[ticker]/page.tsx
export const revalidate = 21600; // 6 hours

export async function generateStaticParams() {
  // Only pre-render the top 1000 most-viewed stocks
  const topStocks = await getTopStocks(1000);
  return topStocks.map(s => ({ ticker: s.ticker }));
}

export default async function StockPage({ params }) {
  const { ticker } = await params;
  const stock = await fetchStockData(ticker);

  if (!stock) return notFound();

  return (
    <>
      <StockHeader data={stock} />
      <IndicatorGrid indicators={stock.indicators} />
      {/* Client components for interactive tabs */}
      <StockTabs ticker={ticker} />
    </>
  );
}

The remaining 99,000 stocks are rendered on first request and cached for 6 hours. This means:

First visitor to an obscure ticker waits ~800ms (SSR)
Every subsequent visitor gets the cached page in ~50ms
After 6 hours, the next visitor triggers a background revalidation
The stale page is served instantly while the new one generates

CSR for the Screener: When Interactivity Wins

The screener is our most interactive page. Users build complex filter groups with AND/OR logic, adjust ranges with sliders, and see results update in real-time. SSR makes no sense here.

// app/screener/page.tsx
'use client';

export default function ScreenerPage() {
  const [filters, setFilters] = useState<FilterGroup[]>([]);
  const [results, setResults] = useState<Stock[]>([]);

  // Debounced API call on filter change
  useEffect(() => {
    const timer = setTimeout(() => {
      searchStocks(filters).then(setResults);
    }, 300);
    return () => clearTimeout(timer);
  }, [filters]);

  return (
    <>
      <FilterBuilder filters={filters} onChange={setFilters} />
      <ResultsTable stocks={results} />
    </>
  );
}

But CSR pages need SEO too. We solve this with a layout.tsx:

// app/screener/layout.tsx
export const metadata = {
  title: 'Stock Screener - 120+ Fundamental Indicators',
  description: 'Screen 100,000+ stocks across 73 exchanges...',
};

export default function ScreenerLayout({ children }) {
  return children;
}

The Server + Client Island Pattern

Our home page uses the "island architecture" - a server-rendered shell with client-side interactive islands:

// app/page.tsx (Server Component)
export default async function HomePage() {
  const stats = await getMarketStats(); // Server-side fetch

  return (
    <main>
      {/* Static server-rendered content for SEO */}
      <HeroSection stats={stats} />
      <FeatureGrid />

      {/* Client island - interactive email capture */}
      <HeroEmailCapture />

      {/* More static content */}
      <TrustIndicators />

      {/* Client island - interactive search */}
      <HomeClientIsland />
    </main>
  );
}

The server components ship zero JavaScript. The client islands hydrate independently. The page loads fast, is fully crawlable, and the interactive parts work as soon as they hydrate.

Performance Results

After implementing this rendering strategy:

Metric	Before (all CSR)	After (mixed)	Improvement
LCP (stock pages)	3.2s	0.8s	75% faster
FCP (home)	2.1s	0.6s	71% faster
JS bundle (screener)	420KB	180KB	57% smaller
Crawled pages (GSC)	28	25,000+	892x more

The biggest win was crawlability. When everything was CSR, Google only indexed 28 pages. After switching stock pages to ISR, Google started discovering and indexing all 100,000+ stock pages.

Lessons Learned

ISR is the default for data-driven pages. Unless you have a reason not to, use ISR. The caching layer is essentially free and the revalidation is invisible to users.
CSR only when you must. Save client-side rendering for genuinely interactive features: search, filters, forms, real-time data. Everything else should render on the server.
Metadata lives in layout.tsx for CSR pages. Client components can't export metadata, but their layout can. This is how you get SEO for interactive pages.
Pre-render your head, lazy-render the tail. For large catalogs, pre-render the top N pages at build time and let ISR handle the rest on-demand. We pre-render 1,000 stocks and let 99,000+ generate lazily.
The standalone build matters. Next.js output: 'standalone' creates a minimal production bundle. After build, copy .next/static and public into .next/standalone/ or your static assets won't work.

The Architecture Decision Framework

Ask these questions for each page:

Is it interactive? (filters, real-time updates, user-specific)
  → YES → CSR ('use client')
  → NO → Continue...

Does it need fresh data?
  → Every request → SSR (no cache)
  → Periodically → ISR (set revalidate)
  → Rarely/never → Static (build-time)

Does it mix static and dynamic?
  → YES → Server component + client islands

I'm Javier Sanz, a software engineer building ValueMarkers - a stock analysis platform serving 100K+ stocks across 73 global exchanges with Next.js 14, FastAPI, and PostgreSQL.

Detecting Earnings Manipulation with the Beneish M-Score: Python Implementation

ValueMarkers — Wed, 25 Mar 2026 05:28:59 +0000

In 1998, students at Cornell University flagged Enron as a likely earnings manipulator using a statistical model. Wall Street analysts were still recommending "buy." The model? The Beneish M-Score. Here's how to implement it in Python.

What is the Beneish M-Score?

Developed by Professor Messod D. Beneish at Indiana University in 1999, the M-Score is a mathematical model that uses 8 financial ratios to detect whether a company has manipulated its reported earnings.

The key threshold: -1.78

M-Score > -1.78: Likely manipulator
M-Score < -1.78: Unlikely manipulator

The 8 Variables

Each variable captures a different dimension of potential manipulation:

Variable	Name	What It Detects
DSRI	Days Sales in Receivables Index	Revenue inflation through receivables
GMI	Gross Margin Index	Deteriorating margins (incentive to manipulate)
AQI	Asset Quality Index	Capitalization of expenses
SGI	Sales Growth Index	High growth (more pressure to manipulate)
DEPI	Depreciation Index	Slower depreciation to boost earnings
SGAI	SGA Expense Index	Disproportionate overhead changes
TATA	Total Accruals to Total Assets	Earnings quality (cash vs. accruals)
LVGI	Leverage Index	Increasing debt pressure

Python Implementation

def beneish_m_score(
    dsri: float, gmi: float, aqi: float, sgi: float,
    depi: float, sgai: float, tata: float, lvgi: float
) -> dict:
    """
    Calculate the Beneish M-Score for earnings manipulation detection.

    Reference: Beneish, M.D. (1999). "The Detection of Earnings 
    Manipulation." Financial Analysts Journal, 55(5), 24-36.
    """
    THRESHOLD = -1.78

    m = (-4.84
         + 0.920 * dsri
         + 0.528 * gmi
         + 0.404 * aqi
         + 0.892 * sgi
         + 0.115 * depi
         - 0.172 * sgai
         + 4.679 * tata
         - 0.327 * lvgi)

    return {
        'm_score': round(m, 4),
        'likely_manipulator': m > THRESHOLD,
        'variables': {
            'DSRI': dsri, 'GMI': gmi, 'AQI': aqi, 'SGI': sgi,
            'DEPI': depi, 'SGAI': sgai, 'TATA': tata, 'LVGI': lvgi
        }
    }


def calculate_variables(current: dict, previous: dict) -> dict:
    """
    Calculate all 8 M-Score variables from financial statements.

    Args:
        current: Dict with current year financials
        previous: Dict with previous year financials

    Required keys: revenue, receivables, cogs, current_assets,
        ppe, securities, total_assets, depreciation, sga,
        current_liabilities, lt_debt, net_income, ocf
    """
    c, p = current, previous

    # DSRI: Days Sales in Receivables Index
    dsri = ((c['receivables'] / c['revenue']) / 
            (p['receivables'] / p['revenue']))

    # GMI: Gross Margin Index
    gm_prev = (p['revenue'] - p['cogs']) / p['revenue']
    gm_curr = (c['revenue'] - c['cogs']) / c['revenue']
    gmi = gm_prev / gm_curr if gm_curr != 0 else 1.0

    # AQI: Asset Quality Index
    hard_c = c['current_assets'] + c['ppe'] + c.get('securities', 0)
    hard_p = p['current_assets'] + p['ppe'] + p.get('securities', 0)
    aq_c = 1 - (hard_c / c['total_assets'])
    aq_p = 1 - (hard_p / p['total_assets'])
    aqi = aq_c / aq_p if aq_p != 0 else 1.0

    # SGI: Sales Growth Index
    sgi = c['revenue'] / p['revenue']

    # DEPI: Depreciation Index
    dep_rate_c = c['depreciation'] / (c['ppe'] + c['depreciation'])
    dep_rate_p = p['depreciation'] / (p['ppe'] + p['depreciation'])
    depi = dep_rate_p / dep_rate_c if dep_rate_c != 0 else 1.0

    # SGAI: SGA Expense Index
    sgai = ((c['sga'] / c['revenue']) / 
            (p['sga'] / p['revenue']))

    # TATA: Total Accruals to Total Assets
    tata = (c['net_income'] - c['ocf']) / c['total_assets']

    # LVGI: Leverage Index
    lev_c = (c['current_liabilities'] + c['lt_debt']) / c['total_assets']
    lev_p = (p['current_liabilities'] + p['lt_debt']) / p['total_assets']
    lvgi = lev_c / lev_p if lev_p != 0 else 1.0

    return beneish_m_score(dsri, gmi, aqi, sgi, depi, sgai, tata, lvgi)

The TATA Variable: The Most Powerful Predictor

Notice the coefficient on TATA is 4.679 - by far the largest weight in the formula. Total accruals to total assets measures how much of a company's earnings come from actual cash versus accounting entries.

# High accruals = earnings don't match cash flow = red flag
tata = (net_income - operating_cash_flow) / total_assets

# A TATA of 0.05 adds 0.23 to the M-Score
# A TATA of 0.15 adds 0.70 to the M-Score
# This alone can push a company past the -1.78 threshold

Companies with high TATA values are generating earnings primarily through accounting entries rather than cash. Research consistently shows these earnings are less sustainable and more likely to be manipulated.

Real-World Example: The Enron Detection

In 1998, Beneish's model flagged Enron with an M-Score well above -1.78. The key red flags:

High DSRI: Receivables growing faster than revenue
High AQI: Increasing "soft" assets (off-balance-sheet entities)
Extreme TATA: Massive gap between reported earnings and cash flow

The bankruptcy didn't happen until 2001, giving the model a 3-year lead time.

Limitations

Not designed for financial institutions: Banks make money differently. The sales/receivables relationship doesn't apply the same way.
False positives in high-growth companies: Rapid growth naturally elevates SGI and can push other variables higher. Not every high-growth company is manipulating.
Backward-looking: The model uses last year's data. By the time you calculate it, the manipulation may have already unwound.
Probabilistic, not deterministic: An M-Score above -1.78 doesn't prove manipulation. It says the financial patterns are consistent with companies that have historically manipulated.

Building a Quality Screen

The M-Score is most powerful when combined with complementary metrics:

def quality_triple_check(piotroski_score, altman_z, beneish_m):
    """
    Combine three academic models for comprehensive 
    financial health assessment.
    """
    checks = {
        'financial_strength': piotroski_score >= 6,  # Piotroski F-Score
        'bankruptcy_safe': altman_z > 1.81,           # Altman Z-Score  
        'earnings_clean': beneish_m < -1.78,          # Beneish M-Score
    }

    passed = sum(checks.values())

    return {
        'checks': checks,
        'passed': f"{passed}/3",
        'verdict': 'PASS' if passed == 3 else 
                   'CAUTION' if passed == 2 else 'FAIL'
    }

References

Beneish, M.D. (1999). "The Detection of Earnings Manipulation." Financial Analysts Journal, 55(5), 24-36.
Beneish, M.D., Lee, C.M.C., & Nichols, D.C. (2013). "Earnings Manipulation and Expected Returns." Financial Analysts Journal, 69(2), 57-82.

I'm Javier Sanz, a software engineer and value investor building tools for fundamental analysis at ValueMarkers.

Implementing the Piotroski F-Score in Python: A Complete Guide for Quantitative Investors

ValueMarkers — Wed, 25 Mar 2026 05:27:34 +0000

The Piotroski F-Score is one of the most elegant tools in quantitative value investing. Developed by Stanford accounting professor Joseph Piotroski in 2000, it distills a company's financial health into a single number between 0 and 9. In this guide, we'll implement it from scratch in Python.

What is the Piotroski F-Score?

The F-Score evaluates 9 binary criteria across three dimensions:

Profitability (4 points): Is the company making money efficiently?
Leverage & Liquidity (3 points): Is the balance sheet improving?
Operating Efficiency (2 points): Are margins and turnover improving?

A score of 8-9 signals strong fundamentals. A score of 0-2 signals financial weakness. In Piotroski's original study, buying high-scoring stocks and shorting low-scoring ones generated 23% annual returns from 1976-1996.

The Implementation

def piotroski_f_score(
    roa: float,
    roa_prev: float,
    ocf: float,
    total_assets: float,
    leverage: float,
    leverage_prev: float,
    current_ratio: float,
    current_ratio_prev: float,
    shares: int,
    shares_prev: int,
    gross_margin: float,
    gross_margin_prev: float,
    asset_turnover: float,
    asset_turnover_prev: float,
) -> dict:
    """Calculate Piotroski F-Score with detailed breakdown."""

    criteria = {}

    # --- Profitability (4 criteria) ---
    criteria['positive_roa'] = roa > 0
    criteria['positive_ocf'] = ocf > 0
    criteria['increasing_roa'] = roa > roa_prev
    criteria['accruals'] = (ocf / total_assets) > roa if total_assets > 0 else False

    # --- Leverage & Liquidity (3 criteria) ---
    criteria['decreasing_leverage'] = leverage < leverage_prev
    criteria['increasing_current_ratio'] = current_ratio > current_ratio_prev
    criteria['no_dilution'] = shares <= shares_prev

    # --- Operating Efficiency (2 criteria) ---
    criteria['increasing_gross_margin'] = gross_margin > gross_margin_prev
    criteria['increasing_asset_turnover'] = asset_turnover > asset_turnover_prev

    score = sum(1 for passed in criteria.values() if passed)

    return {
        'score': score,
        'criteria': criteria,
        'interpretation': interpret_score(score)
    }


def interpret_score(score: int) -> str:
    if score >= 8:
        return "Strong - Robust financial health"
    elif score >= 6:
        return "Good - Financially sound"
    elif score >= 4:
        return "Moderate - Mixed signals"
    elif score >= 2:
        return "Weak - Multiple red flags"
    else:
        return "Very Weak - Significant distress indicators"

Using It with Real Data

Here's how you'd use this with financial statement data:

result = piotroski_f_score(
    roa=0.08, roa_prev=0.06,          # ROA improved
    ocf=500_000_000,                    # Positive cash flow
    total_assets=5_000_000_000,
    leverage=0.35, leverage_prev=0.40,  # Debt decreased
    current_ratio=1.8, current_ratio_prev=1.5,  # Liquidity improved
    shares=1_000_000, shares_prev=1_000_000,     # No dilution
    gross_margin=0.42, gross_margin_prev=0.38,   # Margins improved
    asset_turnover=0.65, asset_turnover_prev=0.60  # Efficiency improved
)

print(f"F-Score: {result['score']}/9")
print(f"Assessment: {result['interpretation']}")
print("\nCriteria breakdown:")
for name, passed in result['criteria'].items():
    status = "PASS" if passed else "FAIL"
    print(f"  {name}: {status}")

Output:

F-Score: 9/9
Assessment: Strong - Robust financial health

Criteria breakdown:
  positive_roa: PASS
  positive_ocf: PASS
  increasing_roa: PASS
  accruals: PASS
  decreasing_leverage: PASS
  increasing_current_ratio: PASS
  no_dilution: PASS
  increasing_gross_margin: PASS
  increasing_asset_turnover: PASS

The Accruals Check - The Most Misunderstood Criterion

Criterion 4 (accruals) is the most subtle. It checks whether operating cash flow relative to assets exceeds ROA. Why? Because earnings driven by actual cash flow are higher quality than earnings driven by accounting accruals.

A company can report positive earnings while generating negative cash flow through aggressive revenue recognition, capitalizing expenses, or other accounting choices. The accruals check catches this.

# This company reports profits but cash flow tells a different story
accruals_check = (ocf / total_assets) > roa

# If ROA is 8% but OCF/Assets is only 3%, 
# earnings are heavily accrual-based = red flag

Limitations to Keep in Mind

The F-Score isn't perfect:

Backward-looking: It compares this year to last year. A company recovering from a bad year scores well even if it's still mediocre.
Sector-blind: The same thresholds apply to capital-intensive manufacturers and asset-light tech companies. A tech company with high leverage might score poorly on criteria that don't apply.
Cyclical sensitivity: In cyclical downturns, even great companies see declining margins and ROA. The score drops not because the company is weak, but because the entire sector is in a trough.
No growth consideration: Two companies with identical F-Scores of 9 could have vastly different growth prospects.

Combining with Other Metrics

The F-Score works best as a filter, not a standalone signal. Combine it with:

Altman Z-Score for bankruptcy risk assessment
Beneish M-Score for earnings manipulation detection
Valuation metrics (P/E, EV/EBITDA, DCF) to find cheap AND healthy stocks

This "Quality Triple Check" approach - using Piotroski, Altman, and Beneish together - gives you a much more complete picture of financial health than any single metric.

Academic Reference

Piotroski, J.D. (2000). "Value Investing: The Use of Historical Financial Statement Information to Separate Winners from Losers." Journal of Accounting Research, 38, 1-41. DOI: 10.2307/2672906

I'm Javier Sanz, a software engineer and value investor. I build tools for fundamental analysis at ValueMarkers.