Web FAQ

Not every web page makes sense in Flutter, but we think Flutter is particularly suited for app-centric experiences:

• Progressive Web Apps
• Single Page Apps
• Existing Flutter mobile apps

At this time, Flutter is not suitable for static websites with text-rich flow-based content. For example, blog articles benefit from the document-centric model that the web is built around, rather than the app-centric services that a UI framework like Flutter can deliver. However, you can use Flutter to embed interactive experiences into these websites.

For more information on how you can use Flutter on the web, see Web support for Flutter.

In general, Flutter is geared towards dynamic application experiences. Flutter's web support is no exception. Flutter web prioritizes performance, fidelity, and consistency. This means application output does not align with what search engines need to properly index. For web content that is static or document-like, we recommend using HTML—just like we do on flutter.dev, dart.dev, and pub.dev. You should also consider separating your primary application experience—created in Flutter—from your landing page, marketing content, and help content—created using search-engine optimized HTML.

That said, as mentioned in the roadmap, the Flutter team plans to investigate search engine indexability of Flutter web.

No, but you can use hot restart. Hot restart is a fast way of seeing your changes without having to relaunch your web app and wait for it to compile and load. This works similarly to the hot reload feature for Flutter mobile development. The only difference is that hot reload remembers your state and hot restart doesn't.

Flutter web apps can run on the following browsers:

• Chrome (mobile & desktop)
• Safari (mobile & desktop)
• Edge (mobile & desktop)
• Firefox (mobile & desktop)

During development, Chrome (on macOS, Windows, and Linux) and Edge (on Windows) are supported as the default browsers for debugging your app.

You can select Chrome or Edge as the target device in Android Studio/IntelliJ and VS Code.

The device pulldown should now include the Chrome (web) option for all channels.

See Creating responsive apps.

No. The file system is not accessible from the browser. For network functionality, use the http package. Note that security works somewhat differently because the browser (and not the app) controls the headers on an HTTP request.

Some plugins require platform-specific imports, particularly if they use the file system, which is not accessible from the browser. To use these plugins in your app, see the documentation for conditional imports on dart.dev.

Dart's concurrency support via isolates is not currently supported in Flutter web.

Flutter web apps can potentially work around this by using web workers, although no such support is built in.

See Preparing a web app for release.

Not currently.

You might need to configure the Cache-Control header returned by your web server. For example, if this header is set to 3600, then the browser and CDN will cache the asset for 1 hour, and your users might see an out-of-date version of your app up to 1 hour after you deploy a new version. For more information about caching on the web, check out Prevent unnecessary network requests with the HTTP Cache.

It is a good idea to be aware of this behavior to avoid an undesirable user experience. After you deploy your app, users might use a cached version of your app (cached by the browser or CDN) for the duration defined by your cache headers. This can lead to users using a version of your app that is incompatible with changes that have been deployed to backend services.

If you wish to defeat these cache headers after each deployment, a common technique is to append a build ID of some sort to the links of your static resources, or update the filenames themselves. For example, logo.png might become logo.v123.png.

<!-- Option 1, append build ID as a query parameter in your links -->
<script src="flutter_bootstrap.js?v=123" async></script>

<!-- Option 2, update the filename and update your links -->
<script src="flutter_bootstrap.v123.js" async></script>

Flutter does not currently support appending build IDs to resources automatically.

If you are using Firebase Hosting, the shared cache (CDN) is invalidated when you deploy a new version of your app. But you might choose to configure your cache headers as follows, so that the browser cache doesn't cache application scripts, but the shared cache does.

{
  "hosting": {
    "headers": [
      {
        "source":
          "**/*.@(jpg|jpeg|gif|png|svg|webp|css|eot|otf|ttf|ttc|woff|woff2|font.css)",
        "headers": [
          {
            "key": "Cache-Control",
            "value": "max-age=3600,s-maxage=604800"
          }
        ]
      },
      {
        "source":
          "**/*.@(mjs|js|wasm|json)",
        "headers": [
          {
            "key": "Cache-Control",
            "value": "max-age=0,s-maxage=604800"
          }
        ]
      }
    ]
  }
}

The service worker generated by flutter build web is deprecated, and you can disable it by setting the --pwa-strategy flag to none when running the flutter build web command.

flutter build web --pwa-strategy=none

If you would like to continue to use a service worker, you can build your own or try third-party tools such as Workbox.

If your service worker is not refreshing, configure your CDN and browser cache by setting the Cache-Control header to a small value such as 0 or 60 seconds.

Unless stated otherwise, the documentation on this site reflects the latest stable version of Flutter. Page last updated on 2024-11-20. View source or report an issue.