Skip to main content
Building & Shipping Products

Web App vs Mobile App for SaaS, and How to Optimise Core Web Vitals

By Obaid Tariq, Founder & Lead Engineer · Published

Disclosure: AI Dev Planner builds web and mobile apps, so we have an interest in this question. We recommend the cheaper web-first route for most SaaS products. See our disclosure policy.

The short answer

For the web app vs mobile app for SaaS decision, most products should start with a responsive web app designed mobile-first, add progressive web app features where they help, and build a mobile app later with React Native and Expo or native code only when the core workflow depends on the device. Responsive design adapts one layout fluidly with CSS; adaptive design serves distinct layouts for set screen sizes or devices. Optimise Core Web Vitals by measuring real users against web.dev's thresholds (LCP 2.5 seconds, INP 200 milliseconds, CLS 0.1) and fixing the specific cause of each slow metric.

Should I build mobile-first, web-first or native mobile applications for my SaaS?

For most SaaS products, build web-first and design mobile-first: one responsive web app that works well on a phone, released without app store review. Add a native or cross-platform mobile app when the core workflow needs the device itself, such as offline use, background location, Bluetooth or heavy camera work, or when your users expect to find you in an app store. If you need an app, React Native with Expo is a sensible default; fully native code suits apps that lean hardest on platform features.

First, separate the three ideas

"Mobile-first" is a design approach: you design for the smallest screen first and add layout as space allows. "Web-first" is a delivery decision: your first client is a web app. "Native" is a technology choice: an app installed from the App Store or Google Play. You can, and usually should, be web-first and mobile-first at the same time. Google's mobile-first indexing documentation says Google uses the mobile version of a site's content for indexing and ranking, and recommends responsive web design as the easiest pattern to implement and maintain, which is one more reason to design for phones from the start.

The options compared

Responsive web app, PWA, React Native with Expo and native apps compared for a SaaS product
OptionStrengthsLimitsBest for
Responsive web appOne codebase, instant updates, no store review, works on any device, indexable by search enginesLimited background work and device access; must be opened in a browserMost B2B SaaS, dashboards, admin-heavy and desktop-heavy workflows
Progressive web app (PWA)Installable, can work offline with service workers, can send push notifications where supportedCapabilities vary by browser and platform; on iOS, web push is limited to web apps added to the Home ScreenWeb apps whose users return often on phones and need light offline support
React Native with ExpoOne JavaScript/TypeScript codebase that runs natively on iOS and Android, over-the-air updates for JavaScript and assetsStore review for native changes; some platform features need native modulesMobile-centred SaaS, field work, consumer-facing companion apps
Native (Swift / Kotlin)Full access to platform APIs and best performance for demanding featuresTwo codebases and two skill sets; slowest and most expensive routeApps built around the device: advanced camera, AR, Bluetooth hardware, heavy background processing

When web-first is right

Start with a responsive web app when your users work mainly at a desk, when the product is about data entry, reports or collaboration, or when you are still testing demand. You ship one client, updates reach everyone at once, and you avoid app store review on every release. For most B2B SaaS this is the faster and cheaper first version; our guide to how long an MVP takes to build explains why building web and native apps at the same time stretches the timeline.

What a PWA can and cannot do

MDN describes a progressive web app as an app built with web platform technologies that can be installed on the device, operate offline and in the background, and integrate with the device. In practice that means a web app manifest for installation, a service worker that caches assets and responses for offline use, and optional push notifications. The limits are real, though: web.dev notes that some capabilities are still out of the web's reach, and support differs by platform. WebKit's announcement of web push for iOS and iPadOS 16.4 says it applies to web apps added to the Home Screen, and permission must be requested after a user interaction, so a PWA's notifications will not reach iPhone users who only use it in a browser tab.

When to build a mobile app

  • The core workflow happens away from a desk: inspections, deliveries, site visits, where offline use and the camera matter.
  • You need reliable background behaviour: location tracking, scheduled sync or Bluetooth devices.
  • Notifications are central and many users are on iPhone without installing a PWA.
  • Your buyers expect an app store listing as a sign of credibility, or your users are consumers who search the stores.

React Native and Expo, or native?

React Native's own documentation recommends using a framework such as Expo for new apps, because most apps need navigation and access to native APIs from the start. Expo's EAS Update can ship changes to JavaScript, styling and images over the air between store releases; changes to native code, permissions or the SDK version still need a new build and store review. For a SaaS team already working in TypeScript and React, that makes React Native with Expo the natural default. Choose fully native Swift and Kotlin when the app's value depends on platform features at the edge of what cross-platform frameworks support, or when you have native specialists already. Our mobile development team builds both.

When native-first is justified

If the product is the mobile experience, such as a consumer app or a field tool whose users never sit at a desk, start with the mobile app and treat the web as the admin console. Even then, keep the first version to one workflow. Our guide to going from idea to launched SaaS covers how to keep that scope tight.

What are the differences between responsive and adaptive design, and how can I optimise Core Web Vitals?

Responsive design uses one fluid layout that reflows with CSS media queries, flexible grids and flexible images; adaptive design serves a set of distinct layouts chosen for specific screen sizes or devices. To optimise Core Web Vitals, measure real-user data at the 75th percentile and fix each metric's cause: for LCP, load the main image or text sooner; for INP, break up long JavaScript tasks; for CLS, reserve space for anything that loads late.

Responsive vs adaptive design

Both terms describe how a site handles different screens, and they are often used loosely. In our usage:

Responsive and adaptive design compared
AspectResponsive designAdaptive design
How it worksOne layout that changes fluidly with CSS: flexible grids, flexbox, media queriesSeveral fixed layouts, chosen by screen size in CSS or by device detection on the server
BreakpointsWherever the content needs themAt a set of target widths or device classes
MaintenanceOne template to maintain and testSeveral templates to keep in step
SearchSame HTML and URL for all devicesIf the server sends different HTML per device, Google's guidance is to keep content equivalent and signal the variation correctly
When it fitsAlmost every SaaS product and marketing siteA legacy desktop site being retrofitted, or a screen that genuinely needs a different interface on phones

web.dev's responsive web design basics recommend a viewport meta tag with width=device-width, initial-scale=1, images with max-width: 100% plus width and height attributes, layouts built with flexbox or grid rather than fixed widths, and breakpoints chosen where the content needs them rather than by device. We default to responsive web design and only add adaptive elements, such as a different component on small screens, where a single layout cannot serve both well.

Core Web Vitals: the current metrics and thresholds

web.dev defines three Core Web Vitals. Interaction to Next Paint (INP) replaced First Input Delay (FID) as the responsiveness metric on 12 March 2024, according to web.dev's announcement. The thresholds below are measured at the 75th percentile of page loads, separately for mobile and desktop.

Core Web Vitals metrics and thresholds published by web.dev
MetricMeasuresGoodNeeds improvementPoor
Largest Contentful Paint (LCP)Loading: when the largest image or text block renders2.5 s or lessOver 2.5 s up to 4.0 sOver 4.0 s
Interaction to Next Paint (INP)Responsiveness to clicks, taps and key presses200 ms or lessOver 200 ms up to 500 msOver 500 ms
Cumulative Layout Shift (CLS)Visual stability: unexpected movement of content0.1 or lessOver 0.1 up to 0.25Over 0.25

Measure with field data from real users first (Search Console's Core Web Vitals report or your own real-user monitoring), then reproduce problems in lab tools such as Lighthouse or Chrome DevTools. Lab scores alone can look fine while real users on slower phones struggle.

How to improve LCP

  1. Find the LCP element for your key pages; it is usually a hero image or a heading.
  2. Make it discoverable in the HTML, not injected by JavaScript or hidden in CSS. If it must be in CSS, preload it.
  3. Prioritise it: web.dev recommends fetchpriority="high" on the likely LCP image and says never to lazy-load it.
  4. Shrink it: correctly sized, compressed images in modern formats such as AVIF or WebP, served from a CDN.
  5. Unblock rendering: reduce render-blocking CSS, defer non-critical scripts, and render the page on the server rather than waiting for client-side JavaScript. See our guide to SPA vs SSR in the Next.js App Router.
  6. Cut server response time (TTFB): avoid redirects, cache at the CDN and speed up slow back-end queries.

How to improve INP

  1. Find slow interactions in field data, then reproduce them with the DevTools performance panel.
  2. Break up long tasks. web.dev defines a long task as one over 50 milliseconds and recommends yielding to the main thread, with scheduler.yield() where supported and setTimeout() as a fallback (it notes Safari does not support scheduler.yield() at the time of writing).
  3. Do the visible update first and defer the rest of the work, such as analytics calls or saving in the background.
  4. Reduce JavaScript: ship less code, remove unused libraries and audit third-party scripts such as chat widgets and tag managers.
  5. Keep the DOM small: very large pages make every update slower. Virtualise long lists, and consider content-visibility for off-screen content.

How to improve CLS

  1. Give images and videos dimensions with width and height attributes or CSS aspect-ratio.
  2. Reserve space for embeds, ads and anything injected late, using min-height or a placeholder.
  3. Do not push content down with banners or cookie notices loaded after the page; overlay them or reserve the space.
  4. Control web fonts: web.dev suggests font-display: optional or a closely matched fallback font to limit layout shifts when fonts load.
  5. Animate with `transform`, not properties such as top or left that trigger layout.
  6. Keep pages eligible for the back/forward cache so returning visitors do not see a fresh layout.

When good enough is enough

For pages behind a login, such as an app dashboard, search ranking is not the goal, but the same metrics still describe how fast the product feels. Prioritise the screens users visit most, aim for the good thresholds there, and do not spend weeks shaving milliseconds off pages few people see. Our launch checklist includes the performance items to confirm before go-live, and our Next.js development team can audit a slow site against field data.

Frequently asked questions

Did INP replace FID in Core Web Vitals?

Yes. According to web.dev, Interaction to Next Paint became a Core Web Vital and replaced First Input Delay on 12 March 2024. INP measures the responsiveness of interactions throughout a visit, not just the first one.

Can a PWA replace a native app?

For many SaaS products, yes: a PWA can be installed, work offline with service workers and send push notifications where the platform supports them. It falls short when you need reliable background work, deep device access, or notifications for iPhone users who have not added the app to their Home Screen.

Is React Native good enough for a SaaS mobile app?

For most SaaS companion apps, in our view, yes. It lets one TypeScript team ship to iOS and Android, and its documentation recommends a framework such as Expo for new projects. Fully native development is worth the extra cost mainly for apps that depend on advanced platform features or very demanding performance.

Do Core Web Vitals affect pages behind a login?

Pages behind a login are not indexed by search engines, so they do not affect search ranking. The metrics still describe how fast and stable the product feels to users, so they are worth measuring on your most-used screens.

Sources

  1. web.dev: Web Vitals — The three Core Web Vitals, good thresholds (LCP 2.5 s, INP 200 ms, CLS 0.1) and measurement at the 75th percentile split by mobile and desktop. Accessed 19 October 2026.
  2. web.dev: Interaction to Next Paint becomes a Core Web Vital on March 12 — INP replaced FID as a Core Web Vital on 12 March 2024. Accessed 19 October 2026.
  3. web.dev: Largest Contentful Paint (LCP) — LCP thresholds: good 2.5 s or less, poor over 4.0 s. Accessed 19 October 2026.
  4. web.dev: Interaction to Next Paint (INP) — INP thresholds: good 200 ms or less, poor over 500 ms. Accessed 19 October 2026.
  5. web.dev: Cumulative Layout Shift (CLS) — CLS thresholds: good 0.1 or less, poor over 0.25. Accessed 19 October 2026.
  6. web.dev: Optimize Largest Contentful Paint — LCP sub-parts and fixes: discoverable LCP resource, fetchpriority, never lazy-load the LCP image, modern image formats, CDN, TTFB. Accessed 19 October 2026.
  7. web.dev: Optimize Interaction to Next Paint — Interaction phases and fixes: yielding, avoiding long tasks, keeping the DOM small, content-visibility. Accessed 19 October 2026.
  8. web.dev: Optimize long tasks — Long tasks are over 50 ms; scheduler.yield() recommended with setTimeout() fallback; scheduler.yield() not supported in Safari. Accessed 19 October 2026.
  9. web.dev: Optimize Cumulative Layout Shift — CLS causes and fixes: image dimensions, reserved space, font-display, transform animations, back/forward cache. Accessed 19 October 2026.
  10. web.dev: Responsive web design basics — Viewport meta tag, flexible images, flexible layouts, media queries and content-driven breakpoints. Accessed 19 October 2026.
  11. Google Search Central: Mobile site and mobile-first indexing best practices — Google uses the mobile version of content for indexing and ranking and recommends responsive web design; equivalent content across device versions. Accessed 19 October 2026.
  12. MDN Web Docs: Progressive web apps — Definition of a PWA and its capabilities: installation, offline operation with service workers, background APIs and the web app manifest. Accessed 19 October 2026.
  13. web.dev: What are Progressive Web Apps? — PWAs are capable, reliable and installable; some capabilities are still out of the web's reach. Accessed 19 October 2026.
  14. WebKit: Web Push for Web Apps on iOS and iPadOS — Web push arrived in iOS and iPadOS 16.4 for web apps added to the Home Screen, with permission requested after user interaction. Accessed 19 October 2026.
  15. React Native: Get Started — React Native recommends using a framework such as Expo for new apps. Accessed 19 October 2026.
  16. Expo Docs: EAS Update introduction — Over-the-air updates for JavaScript, styling and images; native code, permission and SDK changes need a new build. Accessed 19 October 2026.

Recommendations without a source are AI Dev Planner’s own engineering opinion. Platform features and prices change; check the linked pages for the current position. Found an error? See our corrections policy.

Related guides

Browse all 50 questions in the SaaS & web development guide.

Not sure whether you need an app?

Tell us how your users work and on which devices. We will tell you whether a responsive web app is enough, and what a mobile app would add.

Ask about your product Mobile development services