Forem: Subito

Improving Data Fetching in Next.js: Lessons from Moving Beyond useEffect

Chao Fang — Mon, 16 Mar 2026 16:19:02 +0000

At Subito (Italy's leading classifieds platform), we never paid much attention to how we made API calls in our web frontend microsites, all built on Next.js. We had a simple library based on Axios that handled everything: making requests, modeling data, and managing errors.

On the server side, it was a simple call; on the client side, we used useEffect with state management for data and errors. It worked, until we started asking: is this still the right approach?

The Wake-Up Call: The Cloudflare Incident

The turning point was reading about the Cloudflare outage caused by excessive API calls triggered by useEffect.

It made us reflect on our own stack:

Are we over-fetching?
Are we accidentally triggering duplicate requests?
Could we overload our backend without realizing it?

The Mission

Our primary goal was simple: embrace the standard! We wanted to align perfectly with the official recommendations from React and Next.js.

Since our architecture relies on the Next.js App Router to consume REST APIs, we needed a clean, well-defined data-fetching strategy that clearly distinguishes between React Server Components and Client Components.

The Server Side: embracing the standard

For Server Components, the decision was surprisingly easy: Next.js extends the native fetch API, adding powerful caching and revalidation features out of the box.

What we did: we replaced all Axios calls in our Server Components with the native fetch API extended by Next.js.

This "simple" switch allowed us to remove Axios entirely from our code, a library that, while historic, adds ~13kb to the bundle and has had multiple security advisories over the years (Axios served us well for years and played a huge role in making HTTP requests easier across the JavaScript ecosystem; but it was time to move on).

The Client Side: the great debate (React Query vs. SWR)

While the server side was easy, the client side required a comparison between two libraries: TanStack Query (React Query) and SWR.

The React Query Experiment

We started with React Query: it has gained massive popularity in the React ecosystem, and for good reason!
It's incredibly powerful, a true "server state" manager; we had to try it!

What we found: for our use case it felt like overkill: it requires a QueryClient, a Provider, and careful queryKey management.
The learning curve was steeper than expected, and integrating it into our existing microsites wasn't trivial. The mental shift and boilerplate needed slowed down adoption.
On top of that, we don't really need mutations or cache invalidation on the client since our caching is handled server-side by our backend REST APIs.

The SWR "Toy" that Could

Then we tried SWR (Stale-While-Revalidate) by Vercel.
One of our colleagues jokingly called it a "giocattolino" ("a little toy" in italian) because of how simple it is. But for our use case, it was perfect!

Zero Boilerplate: No mandatory providers. Just a hook: useSWR(key, fetcher)
Low Learning Curve: It felt like a natural extension of the platform
Client-only by design: SWR is focused solely on Client Components, exactly what we needed, since we already solved server-side fetching with native fetch

The Migration

The move from useEffect to SWR felt like cleaning a cluttered room. Here's a real example from our codebase:

Before (useEffect):

const [items, setItems] = useState<Array<AdItem>>([]);
const [isLoading, setIsLoading] = useState(true);

// load the Ads
useEffect(() => {
  getRecommendedItems(vertical)
    .then(setItems)
    .finally(() => setIsLoading(false));
}, [vertical]);

After (SWR):

const { data: items = [], isLoading } = useSWR(
  SWR_KEYS.recommender(vertical),
  fetchRecommendedItems
);

We deleted two useState declarations and replaced a bulky useEffect block with a single, declarative hook.

Centralized Key Management

To avoid "magic strings" and ensure consistent caching, we centralized our SWR keys:

export const SWR_KEYS = {
  recommender: (vertical: string) => ['recommender', 'items', vertical] as const,
  user: (userId: string) => ['user', userId] as const,
};

Simple, type-safe, and predictable.

Testing Without the Headache

Since SWR caches globally, we developed a utility to ensure our unit tests stay isolated:

import { render } from '@testing-library/react';
import { SWRConfig } from 'swr';

export const renderWithSWR = (ui: React.ReactElement) => {
  return render(
    <SWRConfig value={{ dedupingInterval: 0, provider: () => new Map() }}>
      {ui}
    </SWRConfig>
  );
};

// Usage: renderWithSWR(<RecommenderWidget />);

Conclusion

By moving away from manual useEffect fetching and adopting the SWR + Native Fetch combo, we've achieved cleaner code and a much more React-standard way to handle data fetching.

Sometimes the simplest tool is the most effective one. Our use case was clear: few mutations on the client side, no shared cache needed between server and client, and no client-side caching required since we're a pure frontend team calling REST services that handle their own caching.

For this scenario, SWR turned out to be the most immediate, simple, and fitting solution. No over-engineering, just the right tool for the job.

The big takeaway: don't just follow the hype. React Query is an amazing library, if you need complex cache invalidation, optimistic updates, or tight server-client state synchronization, it's probably the right choice. For us, it wasn't. Understand your actual requirements first, then pick the tool that fits, not the other way around.

How We Reduced INP by 100ms+: GTM Isolation, React Compiler, and Better Telemetry

Francesca Milan — Tue, 17 Feb 2026 16:19:34 +0000

At Subito (Italy's leading classifieds platforms), we constantly monitor our Core Web Vitals. While we had a handle on LCP and CLS, we were constantly struggling with INP (Interaction to Next Paint) on our high-traffic public pages, specifically our Listing and Ad Details pages.

Unlike LCP or CLS, where we have automated alerts triggering when thresholds are breached, setting up alerts for INP seemed impossible.

What is INP?

For context, INP measures a page's responsiveness. It observes the latency of all user interactions (clicks, taps, and key presses) throughout the lifespan of a user's visit. The final value is the longest interaction observed (ignoring outliers).

According to Google's standards, a "Good" experience is defined by strictly defined thresholds:

🟢 Good: 200ms
🟡 Needs Improvement: Between 200ms and 500ms
🔴 Poor: 500ms

INP is about how "fast" the site feels when you try to use it. A poor INP means the user clicks a button and... waits.

The Problem: "It's Not Just Us"

We struggled with INP because fluctuations weren't always caused by our code.

On our highest-traffic pages, two major actors are almost entirely out of our direct control:

GTM (Google Tag Manager): Managed by our Marketing team.
ADV (Advertising): Managed by our Sales/Advertising team.

Both inject code and event listeners that heavily impact performance.

The Old "Empiric" Way (And Why It Failed)

Previously, our monitoring was purely observational via Grafana. When INP spiked, we would scramble to check recent releases. Most of the time, our code changes weren't the culprit, and rollbacks did nothing.

We resorted to an empiric, frustrating debugging process: open Chrome DevTools, throttle the CPU to 4x, simulate a 4G network, and click around hoping to reproduce the lag. It wasn't wrong, but it was inefficient and lacked engineering rigor.

The "Scientific" Approach: Isolating the Actors

This year, the Frontend Chapter decided to stop guessing. We needed to measure the specific weight of the three actors: Our Code, GTM, and ADV.

With approval from the respective teams, we ran an A/B test on 1% of our traffic:

Segment A: Loaded without GTM.
Segment B: Loaded without ADV.
Segment C: Standard traffic.

This finally gave us clear baselines.

Case Study 1: The Ad Details Page

Here is what we found for the Ad Details page:

Standard INP: 208ms (Needs Improvement)
INP without ADV: 180ms
INP without GTM: 112ms (Good!)

The data was undeniable: GTM was the primary bottleneck.

Case Study 2: The Listing Page

The Listing page was more complex. Even without external scripts, our baseline was high:

Standard INP: 345ms (Very Poor)
INP without ADV: 279ms
INP without GTM: 320ms

Here, removing GTM didn't help much, and removing ADV helped but didn't solve it. We had to dig deeper.

Solving the GTM Issue (Ad Details)

Once we knew GTM was the culprit on the Ad Details page, we collaborated closely with the Marketing team.

GTM works via triggers (events) that inject JavaScript (tags). To find the needle in the haystack, we cloned the GTM workspace for our 1% traffic slice and used a "Bisect" approach (binary search):

We disabled 50% of the triggers.
Monitored the INP.
If improved, the issue was in that 50%. If not, we checked the other half.
Repeat until the specific script is found.

The Verdict: The heavy hitters were tracking scripts for TikTok and Facebook.

Instead of complex engineering workarounds to move these scripts out of GTM, the Marketing team simply agreed to disable the TikTok tracking.

Result: INP dropped from 208ms to ~170ms. We were finally under the 200ms threshold! 🎉

Solving the Complex Issue (Listing Page)

The Listing page was harder because there was no single "culprit."

Step 1: Better Telemetry with Grafana Faro

We integrated Google's web-vitals library to capture attribution data (longestScriptURL, interactionTarget) and sent it to Grafana Faro:

getFaro().api.pushMeasurement(
    {
      type: 'INP',
      values,
    },
    {
      context: beacon,
    }
);

This allowed us to visualize exactly which scripts and which DOM elements were causing delays.

We discovered that clicks on a.index-module_link were problematic. These links had heavy event handlers attached by interstitial ads (full-page ads).

We are still negotiating a fix with the ADV team, but we couldn't just wait.

Step 2: Enter the React Compiler

To optimize the code we did control, we decided to upgrade to Next.js 16 and enable the React Compiler.

The upgrade process wasn't difficult (though switching from Webpack to Turbopack was an adventure for another article).

The Result:
Surprisingly, just enabling the React Compiler significantly dropped our INP:
From 345ms down to 271ms.

It's still not perfect, but it was a massive free performance win. If we calculate the "No ADV" scenario combined with React Compiler, we would actually be under the threshold:

Conclusion

We aren't done yet, but this journey taught us valuable lessons:

Don't Guess, Measure: Isolate your third parties (GTM, ADV) using traffic splitting (even 1-2%). It gives you leverage and data to drive decisions.
React Compiler is Legit: It's not hard to introduce, and it can provide a significant performance boost for free.
Collaborate, Don't Hack: We avoided clever technical workarounds (like the DataLayer yield pattern). Why? Because talking to the Marketing team and solving the root cause is sustainable. Hacks are not.

Next Steps

Enable automated alerting for INP now that we understand the baseline.
Continue optimizing the Listing page to reach the green threshold (sub 200ms).
The Big Goal: Treat Core Web Vitals as business metrics. We want to establish "Performance Budgets" (e.g., GTM gets max 50ms, ADV gets max 50ms) to ensure quality isn't sacrificed for tracking.

How We Automate Accessibility Testing with Playwright and Axe

Bojan — Wed, 10 Dec 2025 13:18:44 +0000

At Subito, accessibility (a11y) is an important requirement for ensuring all users, regardless of their abilities or disabilities, can use our platform effectively. An accessible website improves the user experience for everyone, including those using assistive technologies like screen readers or alternative input devices.

In this article, we'll show you how we use Playwright combined with Axe (@axe-core/playwright) to automatically catch accessibility issues and integrate them into our CI pipeline.

Our Toolkit: Axe + Playwright

We chose Axe, an open-source library from Deque Systems, as our accessibility testing engine. It's well-regarded, easy to use, and provides a JavaScript API to run tests directly in the browser. The @axe-core/playwright package makes integration seamless.

And since we already rely on Playwright for visual regression testing and our end-to-end suite, adding accessibility checks right on top of that felt like the obvious next step.
No new tools to learn, just extending a setup we know well with Axe’s engine running inside the same Playwright workflows.

Configuration

First, we created a helper to get a pre-configured Axe instance. Our configuration focuses on WCAG 2.1 Level A and AA criteria.

What is WCAG? The Web Content Accessibility Guidelines (WCAG are developed by the W3C to make web content more accessible.

Level A: The minimum level of conformance.

Level AA: The mid-range level we (and many others) target, as it addresses more advanced barriers.

Level AAA: The highest, most stringent level.

We also explicitly exclude certain elements that are outside our direct control, such as third-party advertisements positions, to avoid false positives.

// From /test/utils/axe.ts
import { Page } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

const getAxeInstance = (page: Page) => {
  return new AxeBuilder({ page })
    // We decided to target WCAG 2.1 A and AA success criteria
    .withTags(['wcag2a', 'wcag2aa'])
    // We exclude elements we don't control, like ads
    .exclude('[id^="google_ads_iframe_"]')
    .exclude('#skinadvtop2')
    .exclude('#subito_skin_id');
};

Implementation: Generating and Saving Reports

Next, we implemented another helper function, generateAxeReport, to run the analysis and save the results.

// From /test/utils/axe.ts
import { Page } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';
import { Result } from 'axe-core';
import * as fs from 'fs';
import * as path from 'path';

// ... getAxeInstance code from above ...

export const generateAxeReport = async (
  name: string,
  page: Page,
  isMobile: boolean,
  includeSelector?: string
) => {
  let axe = getAxeInstance(page);

  // Optionally scope the analysis to a specific selector
  if (includeSelector) {
    axe = axe.include(includeSelector);
  }

  const results = await axe.analyze();
  const violations = results.violations;

  // Save the results to a JSON file
  await saveAccessibilityResults(name, violations, isMobile);

  return violations;
};

async function saveAccessibilityResults(
    fileName: string,
    violations: Array<Result>,
    isMobile: boolean
) {
    const outputDir = 'test/a11y/output';

    if (!fs.existsSync(outputDir)) {
        fs.mkdirSync(outputDir, { recursive: true }); // Create directory if it doesn't exist
    }

    const filePath = path.join(
        outputDir,
        `${fileName}-${isMobile ? 'mobile' : 'desktop'}.json`
    );

    // We map the violations to a clean object for serialization
    const escapedViolations = violations.map((violation) => {
        return {
            id: violation.id,
            impact: violation.impact,
            description: violation.description,
            help: violation.help,
            helpUrl: violation.helpUrl,
            nodes: violation.nodes, // The specific elements that failed
        };
    });

    fs.writeFileSync(filePath, JSON.stringify(escapedViolations, null, 2));
    console.log(`Accessibility results saved to ${filePath}`);
}

The A11y test

With these helpers in place, adding an accessibility check to any Playwright test is incredibly simple.

// From /test/a11y/example.spec.ts
import { test } from '@playwright/test';
import { generateAxeReport } from '../utils/axe';

test('check Login page', async ({ page }) => {
  await page.goto('/login_form');
  await page.waitForLoadState('domcontentloaded');

  // Just call our helper!
  await generateAxeReport('login-page', page, false);
});

It generates a JSON report for the login-page, essentially, each test run produces a structured JSON output with all the accessibility findings:

Integration with Continuous Integration (CI)

Our workflow is triggered every time our staging environment is updated. The action performs the following steps:

Runs the accessibility tests against a predefined list of critical pages.
Generates the JSON reports.
Updates or creates a dedicated GitHub Issue with the results whenever violations are detected.

Here's what the automated report looks like when posted to our GitHub Issue:

And here is the detail of the violations found:

Why a GitHub Issue? (And Not a Failing Build)

This is a key difference from our visual regression tests, which automatically open a PR and send a Slack notification to the engineer who introduced the visual change.

Since we’ve only recently introduced automated a11y checks, there’s naturally a lot of work to catch up on. We’re fixing issues progressively, but until the overall accessibility debt gets closer to zero, blocking or slowing down the pipeline wouldn’t be sustainable.

At the same time, using a GitHub Issue, we create a persistent record of the accessibility debt; the repo owner is then responsible for triaging these issues, assessing their priority, and scheduling the fixes.

Below is an example of a pull request where we address a record previously logged in the GitHub Issue:

What Automation Really Finds

We had high hopes for catching complex navigation issues, but the reality is that automated tests are best at finding basic problems.

What our tests do catch:

Missing alternative text for images (alt attributes)
Color contrast problems
Semantic HTML errors (e.g., improper heading structure)

What our tests don't catch:

Complex keyboard navigability issues
Clarity or comprehensibility of content

These more complex issues still require manual testing and review by accessibility experts (for now).

What's Next?

We plan to add Slack notifications to our GitHub Action; this notification will fire only when new violations are introduced.
While the GitHub Issue tracks our overall a11y debt, a new problem introduced by a recent deployment to staging needs to be fixed immediately.

Conclusion

Automating accessibility testing with Playwright and Axe doesn’t find every a11y problem, but it gives us a baseline that runs on every PR and helps us catch the obvious issues before they ever reach production.

There’s still plenty we want to explore, but this already feels like a solid step forward.

Check Out Our Code

Example Test: github.com/Subito-it/articles-code/blob/main/a11y-example/test/a11y/example.spec.ts
Axe Utilities: github.com/Subito-it/articles-code/blob/main/a11y-example/test/utils/axe.ts
GitHub Action: https://github.com/Subito-it/articles-code/blob/main/.github/workflows/a11y.yml

How We Catch UI Bugs Early with Visual Regression Testing

Tommaso Ruscica — Wed, 12 Nov 2025 14:33:30 +0000

Visual regression testing is a powerful technique to ensure our web application looks as expected, even as code changes over time. In this article, we walk through what a visual regression testing tool is, why it’s important, and how we implemented it in our CI/CD pipeline using Playwright, GitHub Actions, and Git LFS at subito.it, Italy’s leading online classifieds platform.

What Is a Visual Regression Testing Tool?

A visual regression testing tool automatically detects changes in the visual appearance of an application or website. It works by taking screenshots of pages or components and comparing them to previously approved "baseline" images. If any unexpected differences are found, the tool flags them for review.

Why Do You Need It?

CSS and layout changes can have unintended side effects, breaking parts of the UI in subtle ways. For example:

A global CSS tweak makes buttons unreadable.
A new font or asset isn’t loaded correctly.
A component’s layout shifts, breaking alignment.

Visual regression testing helps us:

Catch these issues early, before they reach production.
Document intentional UI changes over time.
Maintain a consistent user experience.

While this tool seems theoretically useful for supporting delivery, let’s share some real examples from our experience to help you better understand the value of this additional tool.

Example 1: Login modal, Submit button not visible

Our "login in place" feature is designed not to show the vertical scrollbar.
A recent change caused the submit button to be pushed off-screen, making it inaccessible to users (See the left image below).

This login modal is crucial for us at subito.it because it allows users to log in without leaving the current page after an action that requires authentication, such as adding an ad to favorites.
Thanks to our visual regression testing tool, we caught this error.

Both unit tests (using Jest) and integration tests (via Playwright) were still passing because they were both able to click the button programmatically.

Example 2: Forgotten font import in the Home Page

During a recent update to our Home Page, a font import was accidentally omitted from the CSS.
Thanks to visual regression testing, we caught the issue before it went live. The screenshots below show the difference:

You can see how the text looks different due to the missing font, which would have negatively impacted user experience.

Example 3: Bug caused by CSS import reordering in Next.js

Recently, we introduced an ESLint rule to enforce grouping and alphabetical ordering of imports in our files.
The related PR was quite large, and we overlooked the fact that CSS import order matters in Next.js (see docs).
As a result, two CSS rules with the same specificity ended up being swapped in the final generated CSS.

At first glance, the bug was tricky to understand; it even seemed flaky when reviewing the updated snapshot PR:

However, by inspecting the HTML diff in the Playwright report, we noticed that the footer layout had changed because Next.js bundled the CSS rules in a different order:

Example 4: Updated carousel component for Mobile site causing an unintentional change on Desktop

In another case, we updated a carousel component to improve mobile usability. However, this change inadvertently affected the desktop carousel, changing the cards’ dimensions.

We noticed the issue because the PR created by the visual regression tool highlighted differences in the desktop view as well. We expected only one file to be changed (the mobile screen), but the PR showed two files changed.

Upon investigation, we found that the desktop carousel cards were now taller than before:

How Did We Implement Visual Regression Testing?

Using Playwright and its visual comparison feature, we implemented visual tests for our pages.
For example, here is a test for our Login page:

import { expect, test } from '@playwright/test';

test('@only-visual Login', async ({ page }) => {
  test.slow();
  await page.goto('/login_form');
  await page.waitForLoadState('networkidle');
  await page.getByText('Accedi con Google').waitFor({ state: 'visible' });

  // Take a screenshot of the page
  const screenshot = await page.screenshot();

  // Compare the screenshot with the baseline
  expect(screenshot).toMatchSnapshot('login.png', {
    maxDiffPixelRatio: 0.01,
  });
});

When implementing visual tests, you will likely need to fine tune for variables that can invalidate the visual comparison but are outside your control, such as advertising banners, marketing promos, or client-side calls like "recommended ads".
We adopted two approaches:

If a component is outside of our control and not part of the core product experience (for example, a marketing banner), we chose to temporarily hide it during visual testing:

await page.addStyleTag({
  content: `
    #sticky-cta-container { display: none !important; }
    .sticky-cta-bottom-anchor { display: none !important; }
  `,
});

When the component’s size or layout was relevant, or when we wanted to display something in its place, we used Playwright's mask option.
For example, we masked the Google Maps widget and replaced it with a simple placeholder square.

const googleIframe = page.locator('iframe');
const yatmoMapIframe = page.locator('#map');
const screenshot = await page.locator('#layout').screenshot({
  animations: 'disabled',
  mask: [googleIframe, yatmoMapIframe],
});

We also discovered a few additional tips that helped improve the reliability of our visual tests:

Blocking Google Tag Manager (or similar scripts) prevents external resources from being fetched during tests, ensuring consistent screenshots across runs.

  // Block Google Tag Manager to avoid loading external resources
  await page.route(/\/gtm.js/, (route) => route.abort());

Another interesting case we encountered involves images using the "lazy" loading attribute.
Because these images load asynchronously, they can cause flaky results.

Here’s an example of what that looks like:

We implemented this helper to override the loading HTML attribute:

import { Page } from '@playwright/test';

export async function forceLoadLazyImages(page: Page): Promise<void> {
  return page.evaluate(() => {
    for (const image of document.querySelectorAll<HTMLImageElement>(
      'img[loading="lazy"]'
    )) {
      image.setAttribute('loading', 'eager');
    }
  });
}

The GitHub Action

To automate our visual regression testing workflow, we use a GitHub Action; it runs automatically whenever a pull request is merged into the main branch.

The workflow performs a full end-to-end process, made of these key steps:

Run visual regression tests: the action launches Playwright. If any snapshot doesn’t match the baseline, the job flags that an update is needed.
Save test results for reporting: regardless of the outcome, all test reports are collected and stored as build artifacts. This allows merging results from all shards later into a single, comprehensive HTML report.
Update snapshots when differences are detected: when visual mismatches are found, Playwright re-runs in update mode (--update-snapshots), refreshing only the changed images.
Identify and upload modified snapshots: the Action inspects the Git diff to identify exactly which .png files changed.
Merge all reports into a single HTML summary: thanks to Playwright’s merge-reports command, all blob reports from multiple shards are combined into one HTML report. The final report can be downloaded directly from the workflow artifacts and provides a clear visual summary of all changes.
Open a PR with updated snapshots: once all changes are ready, the workflow automatically creates a pull request containing only the modified snapshots.
Notify the author via Slack: finally, the Action sends a Slack notification to the author of the merged PR.

A note on Git LFS

Visual regression testing involves large binary files (mostly .png images). To keep the repository lightweight and fast to clone, we use Git LFS (Large File Storage), which handles these files efficiently without bloating the main Git history.

If you want to explore the complete YAML configuration, including all commands and conditions for each step, you can check it out here:
Full GitHub Action workflow on GitHub

Conclusions

At subito.it we have developed a robust testing strategy:

Unit tests for our components using Testing Library and Jest.
Integration tests for all main user flows, avoiding mocks for backend services except for external providers.
Recently, we added visual regression tests to support style and color updates, focusing on the most important pages and cases like the in-place login.

Our internal process is simple: if an incident occurs, during the post-mortem we ask, "Could this have been prevented with a visual test?" If the answer is yes, we add a new visual test to our suite.

If you are wondering whether we also take snapshots for single components, for now the answer is no, we only do this for entire pages. "Component level" snapshots are on our backlog, and we will likely use another tool for that (spoiler: Storybook).

Evolving Our UI Library: From Custom Components to a Hybrid Radix Approach

Chao Fang — Tue, 07 Oct 2025 13:37:00 +0000

How subito.it, Italy’s leading online classifieds platform, navigated the complexities of UI component libraries, from building everything in-house, to embracing open-source solutions.

Introduction

Building and maintaining an internal UI component library is one of those challenges that seems straightforward until you're deep into it.

At subito, we've experienced this journey firsthand, evolving from building custom components in-house, to experimenting with external Tailwindcss (often simply referred to as Tailwind) based libraries like Spark, and ultimately adopting a hybrid approach centered around Radix.

This is the story of our lessons learned and the pragmatic decisions that shaped our current approach.

Building Our Own: The Custom Component Challenge

Initially, we wanted to build our own components starting from native HTML elements as a foundation.

We had specific design requirements and wanted full control over our component behavior while building on top of standard browser elements like <select>, <input>, and <button>.

However, we quickly discovered that building truly accessible and cross-browser compatible components is far more complex than it appears on the surface.

The main challenges we encountered included:

Browser inconsistencies: What works perfectly in Chrome might behave differently in Safari or Firefox
Accessibility requirements: Implementing proper ARIA attributes, keyboard navigation, and screen reader support requires deep expertise
Performance optimization: Ensuring components perform well across different devices and scenarios
Maintenance overhead: Every custom component becomes a long-term commitment that needs updates, bug fixes, and feature enhancements

We realized that maintaining these internal components was becoming expensive both in terms of development time and ongoing support.

The Tailwind-Based Library Experiment

Recognizing the need for a more sustainable approach, we began looking for external solutions.

Our first attempt involved adopting a Tailwind-based library called Spark, developed by our colleagues at leboncoin.

This seemed like a natural choice given that leboncoin faced similar business requirements and design challenges, plus, the library offered a solid technical foundation and a comprehensive component set.

Integrating this Tailwind-based library into our existing ecosystem proved more challenging than anticipated:

Application-Specific Design: It was designed primarily for complete applications rather than as a foundational library for building other UI libraries, as in our case, where we maintain a UI library used across many microsites.

Tailwind Adoption Challenge: Adopting the Tailwind-based library forced us to integrate Tailwind into our web application, even though we hadn't officially approved it as a development tool.

We were implicitly opening the doors to its usage throughout the codebase.
This generated significant confusion among developers who were left wondering: "Can I now use Tailwind utilities throughout the codebase, or should I continue writing CSS the traditional way?"

Additionally, integrating Tailwind forced us to modify our existing CSS reset and baseline styles to make them coexist with Tailwindcss's own reset styles, adding another layer of complexity to our styling architecture.

The Path to Radix: Finding the Right Foundation

After analyzing the complexities introduced by the Tailwind-based library approach, we decided to step back and reconsider our strategy. This led us to Radix as our core solution.

It proved to be the ideal foundation for several reasons:

Maturity and Reliability: is an incredibly mature library with a strong track record of stability and performance.

Accessibility First: Built with accessibility as a core principle, it handles all the complex ARIA attributes, keyboard navigation, and screen reader support that we struggled with in our custom components.

Community and Contribution: The open-source nature allows us to contribute back to the project and benefit from a large community of developers and maintainers.

AI-Friendly Development: As a widely adopted library, it has excellent AI tooling support. Its popularity means that AI agents and coding assistants have extensive knowledge of Radix patterns, making it incredibly easy to build solutions on top of it with AI assistance.

However, we noticed that Radix and our UX needs are not always perfectly aligned, so we decided to adopt a hybrid strategy.

Our Hybrid Strategy: Radix + Selective Integration

Thanks to Radix modular nature, we are not forced to adopt the entire library but can include only the components we truly need.

This gives us the flexibility to rely on Radix where it provides the most value, while integrating other specialized libraries whenever a specific component offers a better fit for our expectations.

In this way, we embrace a hybrid strategy that combines the robustness of Radix with the freedom to choose the most suitable solution for each case.

For example, since Radix did not provide a dropdown that fully met our needs, we chose to integrate React Select instead of building our own.

Conclusion

Our journey in building a UI library highlighted some key lessons:

creating truly accessible components in-house is costly and time consuming, so leveraging open-source solutions is often the smarter move.
If you’re not ready to fully commit to Tailwind CSS, avoid libraries tightly coupled with it, mixing approaches usually adds complexity instead of value.
Radix proved to be a fantastic foundation: it offers mature, accessible, and behavior-driven components without dictating styling. We read about the Radix maintainers moving on, but we agree with what the author of Shadcn pointed out here.
Mixing and matching the best tools from different open-source libraries, helped us strike a balance between control, quality, and maintainability.

Beyond technology, this journey also sparked a process shift: while our UX/design team used to propose brand-new components, the focus is now on identifying the most suitable ones already available in the open-source ecosystem, contributing when possible, and adapting them to our design system.

This change transforms the relationship between design and engineering:

before, the model was focused on creation,
now, it’s increasingly about curation, research, and adaptation.

At the end of the day, the goal is simple: deliver great user experiences without reinventing every wheel along the way.

From Microsites to Context-Driven Architecture: Lessons Learned

Fabio Arcari — Fri, 05 Sep 2025 21:15:27 +0000

From 12 separate microsites to 6 context-specific ones: the web architecture powering subito.it, Italy’s leading online classifieds platform, and the lessons we learned from overengineering.

Introduction

Four years ago, at subito.it, we had fully embraced the microsite approach.
Every page or small group of pages had its own repository, its own deploy pipeline, and its own infrastructure.
It was the era of the article "Our microsite architecture" published on Adevinta's tech blog, where we proudly described how we had "accelerated the frequency of releases and the independence of teams by applying a microsite approach."

What is a Microsite?

A microsite is an architectural approach where individual pages or small groups of related pages are developed, deployed, and maintained as completely separate applications.
Each microsite typically has its own:

Repository and codebase
CI/CD pipeline and deployment process
Infrastructure and hosting environment
Technology stack (which can differ from other microsites)
Team ownership and responsibility

This approach contrasts with traditional monolithic applications where all pages are part of a single large codebase.
Microsites aim to provide maximum team autonomy and deployment independence, allowing different teams to work on different parts of a website without interfering with each other.

Today, in 2025, we have an update on this architecture: we've found a better balance between agility and maintainability through continuous learning and optimization

The Microsite Era: When Everything Seemed Perfect

The microsite approach we had adopted seemed like the ideal solution for our problems:

Lean pipelines: each microsite had a fast and independent deploy pipeline
Team autonomy: each team could work on their own piece without interference
Independent releases: no mutual blocking between teams

Over time, however, we started noticing the first issues:

Uncontrolled Repository Proliferation, what had started as a strategy for important pages had begun to be applied to secondary pages as well.
Distributed Technical Debt, with 12 repositories to maintain, some pages started falling behind in dependency updates and security patches
Excessive Infrastructure Overhead, each microsite required:
- Monitoring configuration
- Alerting setup
- Pipeline maintenance
- CDN Configuration

The New Strategy: Context-Driven Microsites

Instead of going completely back to a monolith (which would have reintroduced the problem of overly long pipelines), we chose a middle path: context-specific microsites.

Principles of the New Architecture

Context First: we group pages that share the same business domain
Clear Ownership: each microsite remains owned by a specific team
Manageable Size: large enough to justify the infrastructure, small enough to remain maintainable

Our new architecture consolidates related pages into context-specific groupings:

Public Content Hub: All public content pages and SEO-relevant content
Ad Insertion Flow: The entire ad insertion workflow
Authentication Service: Authentication, login and sign-up
Transaction Service: The entire transaction ecosystem
Paid Options Service: Paid services and premium options
User Management Service: Personal area and profile management

The Transition Process

Our migration follows a structured approach with three main phases:

Phase 1: Preparation and Setup
The initial phase focuses on preparing the target microsite to receive the migrated functionality:

Set up dedicated layouts and components in the target architecture
Import and adapt components to the consolidated codebase
Update environment variables and configuration management
Establish monitoring and alerting for the new consolidated service

Phase 2: Quality Assurance and Testing
Before going live, we conduct comprehensive checks:

Execute automated end-to-end (E2E) and manual tests
Validate third-party integrations (e.g., GTM)
Verify page headers, caching policies, and security configurations
Confirm monitoring and metrics collection are correctly implemented

Phase 3: Production Migration and Cleanup
The final phase involves the actual cutover and decommissioning of legacy systems:

Gradual Rollout:

Route traffic progressively from legacy to consolidated microsite
Monitor performance and error rates during the transition

Legacy Cleanup:
Following our established Service End-of-Life procedures, we systematically decommission the old microsite:

Destroy monitoring, alerts, and dashboards
Archive repositories and remove deployment configurations
Clean up infrastructure resources (databases, IAM roles, etc.)
Update routing and add redirects where necessary

Conclusions

Our journey from microsites to a more consolidated approach wasn't a failure of microsite architecture, but rather a maturation of our understanding of when and how to apply it.

What we learned:

Architecture must evolve with business and team needs
Not everything needs to be a microservice/microsite - like any architectural pattern, it has its trade-offs
Context is fundamental, group by business context, not technical convenience
Pages that belong to the same user flow should probably stay together

Today, with our 6 context-driven microsites, we've found a balance that allows us to maintain team autonomy and deployment speed while significantly reducing maintenance overhead.

The path to perfect architecture doesn't exist, but the path to ever-improving architecture does.