I Deployed 12 Flutter Web Apps to Production — Here's What Actually Works

My first Flutter web deployment was a disaster. The app took 8 seconds to load, the browser back button did nothing, and a client called me asking why Ctrl+F didn't find anything on the page. That was 2023. Since then I've deployed 12 Flutter web apps to production — dashboards, internal tools, PWAs, and one public-facing product — and I've built a playbook for what actually works.

This is that playbook. Not the Flutter team's marketing pitch, not a conference talk demo. Real production lessons from shipping Flutter web to real users, complete with the performance optimization patterns I use on every project and the gotchas nobody tells you about until you hit them yourself.

When Flutter Web Is the Right Choice

Flutter web is outstanding for a specific category of applications. If your project fits one of these patterns, it's worth serious consideration:

Internal dashboards and admin panels. This is Flutter web's sweet spot. No one is Googling for your internal tools, so SEO is irrelevant. Users bookmark the URL and come back daily, so the initial load happens once and gets cached. The widget library handles data-heavy UIs — tables, charts, filters, forms — better than most JavaScript dashboards I've built. I covered the architecture behind one of these dashboards in my clean architecture guide.

PWAs (Progressive Web Apps). If your client wants an installable app without the app store overhead, Flutter web with PWA support is ideal. The user hits "Install" from the browser, gets an icon on their home screen, and the app works offline if you implement offline-first patterns. I've built three PWAs for B2B clients who didn't want to deal with App Store review cycles for every update.

Code-sharing with mobile. The real power of Flutter web isn't the web part — it's sharing 70-80% of your codebase with the mobile app. Business logic, state management, data models, and API clients are identical. When I build a startup's mobile app and they later want a web dashboard, the incremental effort is 20-30% of what building from scratch would cost.

When Flutter Web Is the Wrong Choice

I learned these lessons the hard way. If your project matches any of these patterns, use something else:

Content-heavy marketing websites. Blogs, landing pages, documentation sites, e-commerce storefronts — anything where Google search is your primary traffic source. Flutter web renders to canvas, which search engines can't read reliably. I built a marketing site in Flutter web early on and rewrote it in plain HTML/CSS four months later after getting zero organic traffic. This blog you're reading right now is static HTML for exactly that reason.

Simple CRUD applications. If your app is mostly forms, lists, and detail views with no complex visualization, React or Next.js gives you a smaller bundle, better SEO, and a larger hiring pool. Flutter web's strength is complex, custom UI. If you're not using that, you're paying the bundle size tax for nothing.

Projects targeting low-end devices or slow connections. A 2-4MB initial download is fine on modern broadband. It's not fine for users in regions with 2G/3G connections or devices with 1GB of RAM. If your audience includes low-end Android users browsing on mobile data, a lightweight HTML/JS solution will serve them better.

The Three Renderers — And Why Only One Matters Now

Flutter web has gone through three rendering backends. Understanding this history explains a lot of the outdated advice you'll find online:

HTML renderer (deprecated). The original renderer painted Flutter widgets using standard HTML elements and CSS. It produced readable DOM output that search engines could index, but the rendering was inconsistent across browsers and animations were janky. The Flutter team deprecated the HTML renderer in Flutter 3.22.

CanvasKit renderer. This is the JavaScript-based Skia renderer that draws everything on an HTML <canvas> element. It produces pixel-perfect output identical to mobile Flutter but means the entire UI is painted on canvas — no DOM elements, no native text selection, no crawlable content. It's what Flutter web used by default before the WASM shift.

Skwasm (WASM) renderer. The current default. This compiles Dart to WebAssembly and runs the rendering engine in WASM instead of JavaScript. It's significantly faster than CanvasKit for compute-heavy operations. I covered the WASM migration in depth in my WASM performance benchmarks article.

Real Performance Numbers from My Deployments

I measured these numbers across my last 5 production Flutter web apps, all using the WASM renderer with Brotli compression enabled on the server:

For comparison, the same apps on the older CanvasKit JS renderer scored 15-25% slower on FCP and TTI. Moving to WASM was the single biggest performance win I've seen — more impactful than any code optimization. The full benchmark methodology is in my WASM migration article.

The numbers are honest — Lighthouse scores of 60-72 are not going to win any web performance awards. A Next.js app doing the same thing would score 85-95. The tradeoff is codebase sharing with mobile and the UI flexibility Flutter gives you. For internal tools where users don't care about Lighthouse scores, that tradeoff is worth it every time.

Bundle Size Optimization

Bundle size is the number one complaint about Flutter web, and there are real things you can do about it. Here's my optimization checklist:

Tree Shake Everything

# Build with aggressive tree shaking
flutter build web --wasm --release \
 --tree-shake-icons \
 --pwa-strategy offline-first

# Check what made it into the bundle
find build/web -type f -name "*.wasm" -o -name "*.js" | \
 xargs -I{} sh -c 'echo "{}: $(du -h {} | cut -f1)"'

The --tree-shake-icons flag removes unused Material Icons from the bundle. On one project this alone saved 400KB. If you're using community packages that import icon sets, make sure tree shaking catches them.

Font Subsetting

# In your pubspec.yaml, use only the weights you need
fonts:
 - family: Inter
 fonts:
 - asset: fonts/Inter-Regular.ttf
 weight: 400
 - asset: fonts/Inter-SemiBold.ttf
 weight: 600
 - asset: fonts/Inter-Bold.ttf
 weight: 700
# DON'T include all 9 weights if you only use 3

Google Fonts loaded via the google_fonts package fetch at runtime from the CDN, which is fine for web but adds a network hop. For production, I download the fonts, subset them, and bundle them locally. The network request for fonts competes with the WASM download on initial load.

Image Optimization

// Use cached_network_image with proper placeholder
CachedNetworkImage(
 imageUrl: photoUrl,
 placeholder: (context, url) => const SizedBox(
 width: 48, height: 48,
 child: CircularProgressIndicator(strokeWidth: 2),
 ),
 errorWidget: (context, url, error) => const Icon(Icons.error),
 memoryCache: true,
 maxWidthDiskCache: 800, // Don't cache full-res on web
)

Deferred Loading — Split Your App by Route

This is the most impactful optimization most Flutter web developers skip. By default, Flutter compiles your entire app into a single bundle. A user hitting the login page downloads the code for every screen in the app, including the admin settings they'll never visit.

Dart's deferred imports let you split by route:

// lib/routes/app_router.dart
import 'package:go_router/go_router.dart';

// Eager imports — needed immediately
import '../screens/login_screen.dart';
import '../screens/dashboard_screen.dart';

// Deferred imports — loaded on demand
import '../screens/settings_screen.dart' deferred as settings;
import '../screens/reports_screen.dart' deferred as reports;
import '../screens/user_management_screen.dart' deferred as users;

final router = GoRouter(
 routes: [
 GoRoute(path: '/', redirect: (_, __) => '/login'),
 GoRoute(path: '/login', builder: (_, __) => const LoginScreen()),
 GoRoute(path: '/dashboard', builder: (_, __) => const DashboardScreen()),
 GoRoute(
 path: '/settings',
 builder: (_, __) => FutureBuilder(
 future: settings.loadLibrary(),
 builder: (context, snapshot) {
 if (snapshot.connectionState == ConnectionState.done) {
 return settings.SettingsScreen();
 }
 return const Center(child: CircularProgressIndicator());
 },
 ),
 ),
 GoRoute(
 path: '/reports',
 builder: (_, __) => FutureBuilder(
 future: reports.loadLibrary(),
 builder: (context, snapshot) {
 if (snapshot.connectionState == ConnectionState.done) {
 return reports.ReportsScreen();
 }
 return const Center(child: CircularProgressIndicator());
 },
 ),
 ),
 ],
);

On one dashboard project with 14 screens, deferred loading cut the initial bundle from 3.4MB to 1.9MB. The user only downloads what they actually visit. The Dart deferred loading documentation covers the full API — the key rule is that the deferred library must be loaded before you use any of its exports.

// lib/widgets/deferred_route.dart
class DeferredRoute extends StatelessWidget {
 final Future<void> Function() loader;
 final Widget Function() builder;

 const DeferredRoute({
 required this.loader,
 required this.builder,
 super.key,
 });

 @override
 Widget build(BuildContext context) {
 return FutureBuilder(
 future: loader(),
 builder: (context, snapshot) {
 if (snapshot.hasError) {
 return Center(
 child: Column(
 mainAxisSize: MainAxisSize.min,
 children: [
 const Icon(Icons.error_outline, size: 48),
 const SizedBox(height: 16),
 Text('Failed to load page: ${snapshot.error}'),
 const SizedBox(height: 16),
 ElevatedButton(
 onPressed: () => (context as Element).markNeedsBuild(),
 child: const Text('Retry'),
 ),
 ],
 ),
 );
 }
 if (snapshot.connectionState == ConnectionState.done) {
 return builder();
 }
 return const Center(child: CircularProgressIndicator());
 },
 );
 }
}

Routing for the Web

Web routing is fundamentally different from mobile routing because users expect URLs to work. They bookmark pages, share links, use the back button, and open links in new tabs. If your Flutter web app doesn't handle all of these, it feels broken.

Use Path URLs, Not Hash URLs

// main.dart — call this before runApp
import 'package:url_strategy/url_strategy.dart';

void main() {
 usePathUrlStrategy(); // /dashboard instead of /#/dashboard
 runApp(const MyApp());
}

Without this, every URL looks like yourapp.com/#/dashboard/settings. The hash fragment is invisible to servers and breaks expectations. With path strategy, you get clean URLs that work the way users expect them to.

Server-Side Fallback for SPA Routing

With path URLs, your server needs to redirect all routes to index.html so Flutter can handle the navigation. Without this, refreshing /dashboard/settings returns a 404:

# .htaccess (Apache / LiteSpeed)
<IfModule mod_rewrite.c>
 RewriteEngine On
 RewriteBase /

 # Don't rewrite actual files (JS, CSS, images, WASM)
 RewriteCond %{REQUEST_FILENAME} !-f
 RewriteCond %{REQUEST_FILENAME} !-d

 # Send everything else to index.html
 RewriteRule ^(.*)$ /index.html [L]
</IfModule>

# nginx.conf
server {
 listen 80;
 server_name yourapp.com;
 root /var/www/flutter-app/build/web;

 location / {
 try_files $uri $uri/ /index.html;
 }
}

I set up this fallback on every Flutter web deployment. It's easy to forget and the symptom — "my app works fine but breaks when I refresh" — is confusing if you don't know what's happening. If you're using GoRouter, make sure your 404 route catches unknown paths gracefully.

SEO and Flutter Web — The Honest Truth

I'll be direct: Flutter web is bad for SEO. The content is rendered on a canvas element or inside WASM-executed rendering logic. Search engine crawlers see an empty page with a loading spinner until Flutter boots, and even after booting, the text isn't in the DOM — it's painted pixels.

Google's crawler can execute JavaScript and may partially render your Flutter web app, but the results are hit-or-miss. I've tested this on three projects with Google Search Console — some pages get indexed partially, most don't index at all. The WASM renderer is even worse for crawlers because the rendering pipeline is compiled WebAssembly, not JavaScript that the crawler can interpret.

What I Do Instead

<!-- In your Flutter web index.html, add meta tags for the shell -->
<!DOCTYPE html>
<html>
<head>
 <meta charset="UTF-8">
 <title>Your App Name</title>
 <meta name="description" content="Your app description for crawlers">
 <meta property="og:title" content="Your App Name">
 <meta property="og:description" content="Description for social sharing">
 <meta property="og:image" content="https://yourapp.com/og-image.jpg">

 <!-- Noscript fallback for crawlers -->
 <noscript>
 <meta http-equiv="refresh" content="0;url=https://yourapp.com/static/">
 </noscript>
</head>
<body>
 <!-- Flutter takes over from here -->
</body>
</html>

For any page that needs to be found through search, I build it in static HTML. The Flutter web portion lives behind a login screen where SEO doesn't matter. This hybrid approach is what works in production. The marketing site, docs, and blog are all HTML. The app is Flutter. Users don't notice the boundary.

Authentication on the Web

Authentication in Flutter web has web-specific security considerations that mobile Flutter developers often miss. The browser is a hostile environment — any JavaScript on the page can read localStorage, and XSS vulnerabilities can steal tokens.

Firebase Auth (My Default)

// Firebase Auth handles web-specific concerns automatically
import 'package:firebase_auth/firebase_auth.dart';

class AuthService {
 final _auth = FirebaseAuth.instance;

 // Persistence is set to LOCAL by default on web
 // Token refresh happens automatically
 // Supports popup and redirect OAuth flows

 Future<UserCredential?> signInWithGoogle() async {
 final provider = GoogleAuthProvider();
 // Use signInWithPopup on web, signInWithProvider on mobile
 return _auth.signInWithPopup(provider);
 }

 Stream<User?> get authStateChanges => _auth.authStateChanges();
}

Firebase Auth handles the web complexity — token storage, refresh, and session persistence — so I don't have to. For OAuth flows on web, use signInWithPopup() instead of signInWithProvider() because the redirect flow can conflict with Flutter web's SPA navigation.

Custom JWT Auth

// For security-sensitive apps, store tokens in memory only
class TokenService {
 // Token lives in Dart memory — not accessible from JS
 String? _accessToken;
 String? _refreshToken;

 String? get accessToken => _accessToken;

 void setTokens({required String access, required String refresh}) {
 _accessToken = access;
 _refreshToken = refresh;
 }

 void clearTokens() {
 _accessToken = null;
 _refreshToken = null;
 }

 // For non-sensitive apps, SharedPreferences works
 // But NEVER store tokens in localStorage for banking/financial apps
}

Auth Guards in GoRouter

// Protect routes with redirect logic
final router = GoRouter(
 redirect: (context, state) {
 final isLoggedIn = authService.currentUser != null;
 final isLoginRoute = state.matchedLocation == '/login';

 if (!isLoggedIn && !isLoginRoute) return '/login';
 if (isLoggedIn && isLoginRoute) return '/dashboard';
 return null; // No redirect needed
 },
 routes: [
 GoRoute(path: '/login', builder: (_, __) => const LoginScreen()),
 GoRoute(path: '/dashboard', builder: (_, __) => const DashboardScreen()),
 // ... other routes
 ],
);

This pattern ensures that unauthenticated users can't access /dashboard by typing the URL directly, and authenticated users get redirected past the login screen. The redirect runs on every navigation event, including browser back button and page refresh.

Responsive and Adaptive Layout

Flutter web is not mobile Flutter on a bigger screen. Desktop users expect hover states, right-click menus, keyboard shortcuts, and layouts that use the available space. If you just scale up your mobile UI, it looks terrible.

My Breakpoint System

// lib/utils/responsive.dart
class Responsive {
 static const double mobile = 600;
 static const double tablet = 1024;
 static const double desktop = 1440;

 static bool isMobile(BuildContext context) =>
 MediaQuery.sizeOf(context).width < mobile;

 static bool isTablet(BuildContext context) {
 final width = MediaQuery.sizeOf(context).width;
 return width >= mobile && width < desktop;
 }

 static bool isDesktop(BuildContext context) =>
 MediaQuery.sizeOf(context).width >= desktop;
}

// Usage in a layout
class DashboardLayout extends StatelessWidget {
 @override
 Widget build(BuildContext context) {
 if (Responsive.isMobile(context)) {
 return const MobileDashboard(); // Bottom nav, single column
 }
 return const DesktopDashboard(); // Side nav, multi-column
 }
}

Web-Specific Interaction Patterns

// Add hover states that desktop users expect
MouseRegion(
 cursor: SystemMouseCursors.click,
 child: AnimatedContainer(
 duration: const Duration(milliseconds: 200),
 decoration: BoxDecoration(
 color: isHovered ? Colors.blue.shade50 : Colors.white,
 border: Border.all(
 color: isHovered ? Colors.blue : Colors.grey.shade300,
 ),
 ),
 child: yourContent,
 ),
 onEnter: (_) => setState(() => isHovered = true),
 onExit: (_) => setState(() => isHovered = false),
)

// Add keyboard shortcuts
Shortcuts(
 shortcuts: {
 LogicalKeySet(LogicalKeyboardKey.control, LogicalKeyboardKey.keyK):
 const SearchIntent(),
 LogicalKeySet(LogicalKeyboardKey.escape):
 const DismissIntent(),
 },
 child: Actions(
 actions: {
 SearchIntent: CallbackAction(onInvoke: (_) => openSearch()),
 DismissIntent: CallbackAction(onInvoke: (_) => closeDialog()),
 },
 child: yourApp,
 ),
)

For form-heavy pages, I add tab navigation between fields, Enter to submit, and Escape to cancel — things mobile users never need but desktop users instinctively try. The animated transitions also need adjustment — mobile-style full-screen page transitions feel wrong on desktop. I use fade transitions and slide-in panels instead.

My Production Deployment Pipeline

Every Flutter web project I deploy follows this build and deploy sequence:

#!/bin/bash
# deploy-web.sh — my Flutter web deployment script

set -e

echo "=== Building Flutter Web (WASM) ==="
flutter build web --wasm --release \
 --tree-shake-icons \
 --dart-define=ENV=production \
 --dart-define-from-file=.env.production

echo "=== Compressing with Brotli ==="
find build/web -type f \( -name "*.js" -o -name "*.wasm" -o -name "*.html" -o -name "*.css" \) \
 -exec brotli --best {} \;

echo "=== Deploying to Firebase Hosting ==="
firebase deploy --only hosting

echo "=== Verifying deployment ==="
curl -sI https://yourapp.com | head -5
echo "Done."

The build flags matter: --wasm enables the WASM renderer, --tree-shake-icons prunes unused icons, and --dart-define-from-file injects environment-specific configuration without hardcoding values in Dart. I covered secure configuration injection in my security guide.

For Firebase Hosting specifically, the firebase.json configuration handles caching, compression, and SPA routing:

// firebase.json
{
 "hosting": {
 "public": "build/web",
 "ignore": ["firebase.json", "**/.*"],
 "rewrites": [
 {
 "source": "**",
 "destination": "/index.html"
 }
 ],
 "headers": [
 {
 "source": "**/*.wasm",
 "headers": [
 { "key": "Content-Type", "value": "application/wasm" },
 { "key": "Cache-Control", "value": "public, max-age=31536000, immutable" }
 ]
 },
 {
 "source": "**/*.js",
 "headers": [
 { "key": "Cache-Control", "value": "public, max-age=31536000, immutable" }
 ]
 },
 {
 "source": "index.html",
 "headers": [
 { "key": "Cache-Control", "value": "no-cache" }
 ]
 },
 {
 "source": "**",
 "headers": [
 { "key": "Cross-Origin-Opener-Policy", "value": "same-origin" },
 { "key": "Cross-Origin-Embedder-Policy", "value": "require-corp" }
 ]
 }
 ]
 }
}

Server Configuration for Flutter Web

If you're deploying to your own server (not a managed platform like Firebase or Vercel), you need to configure MIME types, compression, caching, and the CORS headers:

# .htaccess for Apache / LiteSpeed
# WASM MIME type
AddType application/wasm .wasm

# Brotli / Gzip compression
<IfModule mod_deflate.c>
 AddOutputFilterByType DEFLATE text/html text/css application/javascript application/wasm
</IfModule>

# Cache static assets aggressively
<IfModule mod_expires.c>
 ExpiresActive On
 ExpiresByType application/wasm "access plus 1 year"
 ExpiresByType application/javascript "access plus 1 year"
 ExpiresByType text/css "access plus 1 year"
 ExpiresByType image/png "access plus 1 year"
 ExpiresByType image/webp "access plus 1 year"
</IfModule>

# COOP/COEP headers for SharedArrayBuffer support
<IfModule mod_headers.c>
 Header set Cross-Origin-Opener-Policy "same-origin"
 Header set Cross-Origin-Embedder-Policy "require-corp"
</IfModule>

# SPA fallback routing
<IfModule mod_rewrite.c>
 RewriteEngine On
 RewriteCond %{REQUEST_FILENAME} !-f
 RewriteCond %{REQUEST_FILENAME} !-d
 RewriteRule ^(.*)$ /index.html [L]
</IfModule>

The WASM MIME type is the one that bites most developers. If your server serves .wasm files as application/octet-stream, some browsers refuse to compile them. I've debugged this twice on client projects where "the app works locally but not in production" turned out to be a missing MIME type.

Debugging Flutter Web in Production

When things go wrong in production, you can't just attach a debugger. Here's my debugging toolkit:

Structured Logging

// Use package:logging for structured production logs
import 'package:logging/logging.dart';

final _log = Logger('AppName');

void setupLogging() {
 Logger.root.level = Level.INFO;
 Logger.root.onRecord.listen((record) {
 // In production, send to your error tracking service
 if (record.level >= Level.SEVERE) {
 errorReportingService.capture(
 message: record.message,
 error: record.error,
 stackTrace: record.stackTrace,
 level: record.level.name,
 );
 }
 // In debug mode, also print to console
 assert(() {
 print('${record.level.name}: ${record.message}');
 return true;
 }());
 });
}

Error Boundaries

// Catch rendering errors with ErrorWidget.builder
void main() {
 ErrorWidget.builder = (FlutterErrorDetails details) {
 // Log the error
 _log.severe('Widget error', details.exception, details.stack);

 // Show a user-friendly error in production
 return const Center(
 child: Text('Something went wrong. Please refresh the page.'),
 );
 };

 // Catch async errors
 FlutterError.onError = (details) {
 _log.severe('Flutter error', details.exception, details.stack);
 };

 runApp(const MyApp());
}

The browser console is also useful — Flutter web logs rendering performance warnings there. I've caught memory leaks by watching the Chrome DevTools memory tab over time. If you're investigating rendering performance issues, the Chrome Performance tab shows frame timing for Flutter web the same way it shows it for any web app.

Mistakes I Made Along the Way

These cost me hours or days to fix. Skip them:

Building a marketing site in Flutter web. I mentioned this earlier but it bears repeating. I spent three months building a polished marketing site in Flutter web. It looked beautiful. It got zero organic traffic. Google couldn't index it. I rebuilt it in HTML in two weeks and organic traffic started within a month. Use Flutter web for apps, not websites.

Skipping deferred loading. My first dashboard shipped as a 4.2MB monolithic bundle. Users on the login screen downloaded the code for 14 screens they hadn't even seen yet. After implementing deferred loading, the initial load dropped to 1.9MB and the login page rendered in half the time.

Ignoring browser navigation. I built a multi-step form wizard that worked perfectly on mobile. On web, pressing the browser back button exited the entire app instead of going back one step. Desktop users use the browser back button constantly — your Flutter web app needs to handle it at every navigation level.

Not testing on slow connections. My app loaded fast on my office fiber. A client in a rural area waited 12 seconds. I started testing every deployment on Chrome DevTools' "Slow 3G" throttle. It's humbling but essential.

Using mobile-style navigation on desktop. A hamburger menu on a 27-inch monitor is absurd. I now build completely separate navigation — side drawer on desktop, bottom nav on mobile — using state management that adapts to the platform.

Hardcoding the base href. If your Flutter web app isn't hosted at the domain root (e.g., it's at yoursite.com/app/), you need to set the base href in index.html. I deployed an app that worked locally and broke completely in production because it was served from a subdirectory. The fix is one line:

<!-- In web/index.html -->
<base href="/app/">

<!-- Or set it during build -->
<!-- flutter build web --base-href /app/ -->

My Flutter Web Production Checklist

I run through this list before every Flutter web deployment. Some of these I learned from the mistakes above, and some from deploying e-commerce apps and financial dashboards where production bugs have real consequences:

Most production issues I've debugged trace back to something on this list that was missed. Server configuration (MIME types, headers, routing) causes more deployments issues than Dart code bugs. When a Cloud Functions backend works fine but the web frontend fails, it's almost always a server config problem.

Flutter web in production is a different discipline than Flutter mobile. The framework handles the rendering, but everything around it — deployment, caching, routing, auth, SEO, server config — requires web expertise. The good news is that once you build the deployment pipeline and learn the gotchas, every subsequent project reuses the same patterns. My twelfth Flutter web deployment took a fraction of the time my first one did.

If you're considering Flutter web for your next project, start with an internal tool or admin dashboard. The stakes are lower, the audience is forgiving, and you'll learn the deployment patterns without the pressure of a public launch. Once that's running smoothly, you'll have the confidence and infrastructure to build bigger.