Server-side rendering for Flutter web

[wliumelb]

Status: If your interest is in SEO, see #46789; otherwise, see #47600 (comment).

---

As an app/web developer, I think Server-side rendering may offer a few advantages:

1. Easier search engine optimization.
2. Better loading time in some cases. Older devices may take a little longer to run the Javascript code. Also for applications that need to call a few REST APIs before rendering content, SSR may use caching to significantly reduce delay.
3. Better compatibility. Browsers still use different JS engines, therefore, rendering content from JS code on the front-end may sometimes get different results on different devices. Plain HTML will be much more likely to get rendered consistently.

Is there any chance that Flutter web will support SSR in the future?

[acnologia000]

• i don't think what you are proposing is possible let alone practical as flutters design was aimed to be client side
• devices are slowly becoming more and more powerful , average network speeds are also on rise , flutter team is working very hard in order to improve performance and js bundle size , lets have faith in them
• with technologies like wasm and css paint API on horizon ( i dont know if flutter team will touch them or not ) things like better performance and smaller bundle size are even more practical
• client side rendered SPAs are much more data efficient and snappy once they have been loaded and cached

[wliumelb]

@acnologia000 The point is not choosing one over another. SSR can definitely be a very useful supplementary feature for a client-side web framework, especially for developers aiming to achieve the best possible user experience. With SSR, a static page can be loaded before running any Javascript code, so the user can immediately see something even if they are on a bad network and the js file fails to download.

The current top front-end web frameworks (React, Angular and Vue) all support SSR. Not all web developers use this feature, but some do consider it necessary for their projects.

[zwl1619]

SSR, PWA(already existed), GraphQL, I need all of them.

[wliumelb]

This project looks interesting.
https://github.com/aloisdeniel/bluff

[mahenn]

Need SSR for SEO. Without that we should not take risk of front end development. Even for angular google has universal. In absence of such tool will have to use prerender.io for SEO.

[joepio]

Flutter uses the canvas for all UI rendering, including text. This enables a high degree of control over each pixel (which is awesome for cross-platform animation consistency), but it also has a few downsides:

• screen readers (and crawlers for SEO) can't read the content
• no native keyboard support / native scrollbars
• no cursor-changing native hover interactions
• slower initial loading times on clients
• no support for legacy browsers

If flutter for web could create sensible, machine-readable HTML trees, these issues would be fixed (but we'd probably miss the smooth, cross-platform animations). However, many of these browser functionalities can also be fixed by re-implementing them in Flutter. Flutter could have default cross-browser scrollbars that listen to keyboard events, it can use JS to change hovering cursors, it can set some custom HTML tags for seo... And maybe server side rendering would mean that the Flutter internal state is calculated server side to speed up initial rendering.

I'm really wondering whether Flutter-to-HTML is something that we'll ever see. Perhaps a server-side static site generator without animations and with limited interactivity (opening links, maybe filling forms) would tick most boxes. But I expect an immense set of issues with that approach too.

[rodydavis]

#41927

[realharry]

+1 for flutter ssr.

I don't think it'll be that difficult to implement this once we have html rendering. Many client side web frameworks provides ssr. (e.g. ReactDomServer for react, Angular Universal for angular, etc.)

[thanhdatvo]

We use nodejs to render React, Angular, and Vue in serverside
We can use dart to render Flutter in server side, I suppose
This should be an easy task

[c5n8]

To anyone who says it's easy and not that difficult, it's not easy.

[sweepy84]

I would like Flutter team to help me understand what is the point of having a web version of the app that is not SEO capable? Web is not like any other platform and the vast majority of apps NEED Web to be feasible, so why bother with Web at all?

Sure some apps (e.g. Admin apps) wouldn't need it but MOST would.

An explanation from the Flutter team would be nice.

[wfe8006]

Not sure if this helps: https://developers.google.com/web/tools/puppeteer/articles/ssr

[richard-flosi]

Has anyone tried using ServerSideRenderer from universal_html?

The universal_html package includes a ServerSideRenderer.

Server-side rendering
The package comes with ServerSideRenderer, which is a web server for rendering your web application in the server-side.

import 'package:universal_html/driver.dart';
import 'package:universal_html/html.dart';

void main() {
  final renderer = new ServerSideRenderer(webAppMain);
  renderer.bind("localhost", 12345);
}

void webAppMain() {
  document.body.appendText("Hello world!");
}

https://pub.dev/packages/universal_html#server-side-rendering

[BeliliFahem]

On several projects, we choose ionic framework instead of Flutter, only because of SEO & SSR. And we, the developers, were really disappointed with this arbitration, because apart from this point Flutter is the best technology for the projects in question :'( .

[adityapatnaik]

I would like the Flutter team to help me understand what is the point of having a web version of the app that is not SEO capable? The web is not like any other platform and the vast majority of apps NEED Web to be feasible, so why bother with Web at all?

Sure some apps (e.g. Admin apps) wouldn't need it but MOST would.

An explanation from the Flutter team would be nice.

I may not agree on what is the point of having a web version of the app that is not SEO capable? or in other words apps not using nextjs or just built on CSR(like flutter) are not SEO friendly?

• With the increasing demand for CSR single page applications everywhere, do you think Googlebot(Googlebot is the generic name for Google's web crawler) won't crawl well over a gazzilion of CSR sites and skip all that content?

The truth lies here on webmaster guidelines by Google

Following the General Guidelines below will help Google find, index, and rank your site.

• Googlebot was designed to be run simultaneously by thousands of machines to improve performance and scale as the web grows. Also, to cut down on bandwidth usage, we run many crawlers on machines located near the sites that they might crawl. Therefore, your logs may show visits from several machines at google.com, all with the user-agent Googlebot. Our goal is to crawl as many pages from your site as we can on each visit without overwhelming your server's bandwidth. If your site is having trouble keeping up with Google's crawling requests, you can request a change in the crawl rate.

• Make sure Googlebot is not blocked

• Feedfetcher collects and periodically refreshes these user-initiated feeds, but does not index them in Blog Search or Google's other search services (feeds appear in our search results only if they've been crawled by Googlebot)

• Enabling your site for APIs-Google

  • APIs-Google does not crawl the web randomly; you must register to receive push notifications for an API to be called.

  • APIs-Google uses HTTPS to deliver push notifications, so it requires your site to have a valid SSL certificate. Invalid certificates include the following:

      - Self-signed certificates.
      - Certificates signed by an untrusted source.
      - Certificates that have been revoked.
    

  • Avoid unnecessary retry requests by ensuring that your application is well-designed and responds promptly to notification messages (within seconds).

• If your site has been converted to mobile-first on Google, then the majority of Googlebot crawl requests will be made using the mobile crawler, and a minority using the desktop crawler. For sites that haven't yet been converted, the majority of crawls will be made using the desktop crawler. In both cases, the minority crawler crawls only URLs that have already been crawled by the majority crawler.

• A sitemap tells Google which pages and files you think are important in your site, and also provides valuable information about these files: for example, for pages, when the page was last updated, how often the page is changed, and any alternate language versions of a page. You can use a sitemap to provide information about specific types of content on your pages, including video and image.

Conclusion

Agreed, SSR sites make it easy for crawlers to index pages by providing HTML content as soon as page loads as it's already pre-rendered which means the search engine can request, crawl and index it immediately, CSR, in contrast, HTML needing to be indexed is only revealed when the JS is done with its execution.

The Googlebot has become smart enough to understand dynamic js content and index accordingly if the above guidelines are followed/implemented/met.

Last Words

We are approaching an architecture agnostic approach in terms of SEO.
The focus should be more on developing scaled apps that are not cluttery and are more reactive. SSR could be used to bring down the Time to first byte (TTFB) and other performance parameters, but that doesn't change how GBot perceives CSR sites.

[kenberkeley]

@BeliliFahem Well, maybe you can try react-native-web...

Example

[acnologia000]

@acnologia000 The point is not choosing one over another. SSR can definitely be a very useful supplementary feature for a client-side web framework, especially for developers aiming to achieve the best possible user experience. With SSR, a static page can be loaded before running any Javascript code, so the user can immediately see something even if they are on a bad network and the js file fails to download.

The current top front-end web frameworks (React, Angular and Vue) all support SSR. Not all web developers use this feature, but some do consider it necessary for their projects.

flutter is designed in a way for low level rendering , pixel by pixel
i think this might become a time sink for flutter team

[CavalcanteLeo]

The world is moving from downloaded apps from apple store and google play to PWA, installed via browsers.
Not only flutter have to think about this, but also google, bing and all others.
Google should have more ways to parse the content instead of only reading tags and barely few JS files, should have more ways to read canvas, dunno how, but would be a game changing

Also flutter could provide a SSR version that parses only on crawlers

on binary apps, flutter compiles for both IPA and APK, on web flutter could compile canvas and some SSR

I have no idea how, but one thing I know, nothing is impossible

And SEO is a must have feature, as mentioned before, imagine an e-commerce, it's impossible to have an e-commerce without SEO

and further more, flutter should also give support for google amp, json-ld and facebook instant articles

[Hixie]

Status update:

For indexability (SEO) specifically, please refer to #46789. Indexability can be addressed without server-side rendering. The rest of these thoughts are about server-side rendering for Flutter web ignoring the indexability/SEO context.

Flutter for web, as currently designed, is fundamentally a client-side technology. Dart is compiled to JS (or maybe one day Wasm, we're looking into that in the coming year). That code generates graphics in one of two ways: OpenGL calls via a Wasm-compiled Skia backend that uses WebGL (the preferred option), or 2D graphics via the canvas DOM API (combined in some cases with some carefully positioned DOM nodes to work around limitations of the canvas API; this is less preferred but has less download overhead). For accessibility, the code can also generate DOM nodes with ARIA annotations.

The generation of these graphics and DOM nodes is driven by the Flutter framework's scheduler, which is designed to work with user input (e.g. DOM events) and browser-driven animation timing (scheduled frame callbacks).

Because Flutter paints every single pixel, each frame is essentially a newly-generated PNG. Scrolling is done by responding to the input events by painting a scrolled frame. Content that isn't on the screen is generally not even represented by any widgets (e.g. lists are lazily loaded). Cursors blink because we literally repaint them every half second. If you resize the screen, the whole image is repainted at the new size.

One could imagine running this on the server, but the result would be a single PNG of a particular size, with no animation and no interactivity. It's not clear to me that this is what people are looking for, but maybe I'm wrong. If someone is interested in doing this, I would start by looking at headless WebGL implementations for Node.js, e.g. https://github.com/stackgl/headless-gl, combined with mechanisms for running Wasm on Node.js. It would probably require quite a lot of effort to make that work well, but I haven't tried. It is unlikely to be something that the people currently contributing to Flutter's web port would work on because it doesn't seem to have any obvious valuable applications. It would be significantly easier (and would generate the same output) to just use Flutter's Linux port, which already supports headless operation and generating screenshots (e.g. we use this for golden tests).

One could also imagine completely changing how Flutter approaches web rendering. Instead of painting pixels every frame, a framework could output DOM nodes, more like React or Compose for Web. This would be a radically different framework than what we have now, and would require dropping what I personally think is the most compelling feature of Flutter for web — the ability to run almost unmodified Flutter code on any platform (because a version of Flutter that targeted idiomatic DOM nodes would not be generating anything useful on other platforms). It would trade the flexibility and portability of the existing approach for a much more web-integrated solution.

I think it would be an interesting thing to build with Dart. You could still benefit from hot reload and other core features of Flutter; indeed, you could even create such a framework in such a way that it was backed by code that rendered scenes using the Flutter engine on other platforms (basically you'd need to reimplement the subset of HTML+CSS that the web part relied on; not a trivial task, but significantly more tractable than creating a browser from scratch). Such a system could reuse Flutter's plugin architecture; it would only need to replace the rendering, widgets, and material layers (Flutter is explicitly designed to make that tractable). I would be happy to work with a team doing this to make sure the core Flutter engine and low-level framework primitives were suitable for both projects.

At this time, the people contributing to Flutter's web port are not considering creating such a separate framework. Very early work on Flutter for web did look at reimplementing the material library widgets using such a technique, but we could not achieve the fidelity we were looking for with that approach.

With that as context, to be frank, I do not think there is a viable path towards a version of Flutter that is compatible with today's Flutter code that can render to idiomatic HTML on the server and then bootstrap into either the WebGL/canvas mode or into an interactive generated DOM using idiomatic HTML. Such a thing, if it is possible at all, would require an astounding amount of work. I think if your requirements include using idiomatic HTML, then Flutter with today's framework is not the right choice for you, and I would recommend either using an existing framework specifically designed for the web, or (if you like Dart and features like Hot Reload) creating a new one using Flutter's engine as a base.

[wtfiwtz]

Frameworks such as Next.js (React - https://nextjs.org/) and Nuxt.js (Vue.js - https://nuxtjs.org/) handle this much better, with SEO out-of-the-box. The issue with Nuxt.js is that it is still transitioning between versions (open source maintainers, without commercial backing), so give it a few months (or contribute!). You might end up implementing something in v2 that then needs to be migrated to v3.

Svelte (https://svelte.dev/) also has a very good story, but most of the freely available controls did not handle Server Side Rendering (SSR) or Static Site Generation (SSG) at the moment. You might need to implement your own versions of things like data tables in that instance.

Most of these frameworks are closely aligned to Node.js but I believe you could get Svelte working with a Rollup.js friendly back-end such as Ruby on Rails.

Perhaps you might have some luck with Flutter on prerender.io but I haven't personally tested this. My understanding is Flutter has different rendering modes but I'm not sure how HTML-friendly the available modes are right now if it relies heavily on HTML Canvas for rendering the individual pixels themselves in real-time.

[franzitobambino]

Any updates this year on this topic?

[Hixie]

The current status is described in my last comment literally three comments above this one. :-)

[franzitobambino]

@Hixie I love common sense - a Google made framework is bound to get SEO nailed down eventually! Flutter and WASM! Bring it! The drawbacks of the web platform does not affect me in the context of my audience and staff size - I continue to bet on Flutter and when there's a great team and community - it's only a matter of time !

[franzitobambino]

Hey Team,
Since Flutter web compiles to JavaScript, you think a solution like www.prerender.io can be made for Flutter? If not @Hixie why not?

[cedvdb]

Probably not. The answer to why not is also in the same comment that was linked to you previously.

Although I'm curious to know whether the html renderer works anywhere near what's described in that comment.

Honnestly don't get your hopes up for this, this is probably not going to come in the nearest term.

[Mohsen7s]

@inthelightofthetruth Let me answer you in simple words, think of flutter as a 2D game engine where you develop a game UI with additional OS environment access. Did you even seen a game to render differently on different platforms ? No, the same applies for flutter for the same reason. Did you ever seen somebody to make game-rendered-content be searchable or indexable by search engine ? No, because this is stupid and near-unfeasible without any significant gain.
This issue should have been closed as wont-fix long time ago.

[franzitobambino]

@inthelightofthetruth Let me answer you in simple words, think of flutter as a 2D game engine where you develop a game UI with additional OS environment access. Did you even seen a game to render differently on different platforms ? No, the same applies for flutter for the same reason. Did you ever seen somebody to make game-rendered-content be searchable or indexable by search engine ? No, because this is stupid and near-unfeasible without any significant gain. This issue should have been closed as wont-fix long time ago.

Hey @Mohsen7s ,
If more views like yours gets the light of day then the thread becomes more rich - won't fix is a strong suggestion as I'd rather say "maybe someday" at the end of the day I am gonna take the expert's advice and read Google's suggestions for better SEO rather than berate great platforms like Flutter - I am committed to using Flutter on my app and I have some SEO tricks to use (paid and unpaid). On a higher plane let's not restrict comments or contributions just because they emanate from different paradigms or even a lower state of understanding - no human knows everything about anything! Thanks for your contribution

[siva636]

Hey @Mohsen7s
If what you say is correct, I wonder how is packages like seo_renderer possible?

[franzitobambino]

Keep it coming team - I feel better about my choice everyday lol

[Hixie]

Recent discussion on this thread has not been welcoming, and that is a violation of our code of conduct.
Please reconsider how you communicate in this community before posting again.
All communications should be welcome to everyone. A pleasant cooperative tone is expected at all times.
If you find yourself wanting to post an unfriendly or sarcastic message, then delete it and take a break.
Thank you.

[agelospanagiotakis]

Hey @Mohsen7s If what you say is correct, I wonder how is packages like seo_renderer possible?

this is only for the "inpage SEO" elements
not the meta tags that everybody want.
Facebook and Twitter will not wait for these metatags to refresh !

[fodedoumbouya]

Any updates on this topic?

[iapicca]

Reference in n

@fodedoumbouya
I suspect that p3 means that nobody is working on this at the moment

[mrgzi]

I created a proposal about this. We need more people's opinion about Dom Renderer

[fodedoumbouya]

Reference in n

@fodedoumbouya I suspect that p3 means that nobody is working on this at the moment

oh ok thank you

[fodedoumbouya]

I created a proposal about this. We need more people's opinion about Dom Renderer

Thank you and I will follow up for any news

[MuhammedOzdogan]

There are tons of different technologies out there for web and SSR but there is not a single cross platform framework as efficient as Flutter. There is always a tradeoff. Flutter should stay as performant as possible, SSR is not something must to have. Plus you can prepare a HTML page with other technologies for your SSR needs and then you can embed your Flutter Application into a DOM element.

[amrgetment]

@MuhammedOzdogan Flutter will support WASM soon, it is already in the master branch so SSR+WASM will not affect the performance in my humble opinion