Unmetered version available at blog.remelehane.dev

I hope you enjoyed the first part of this series where I covered SEO and Web Scrappers and their bearing on using Flutter for Web, if you have not read it yet, it is definitely worth checking out first.

In this part, we go into one of the other big SEO factors, performance, while search engines are scraping the text content of your website in order to be able to analyze and categorize what it may be about for later use when a user searches, they are also paying close attention to the performance of your website.

Performance is measured in a few ways, of the more important ones to consider and probably the easiest ones we as developers can solve or at least mitigate is download time and time to first meaningful paint.

Download Time…

Download time should be pretty obvious, but that is how long it takes for your website to finish downloading to the user’s browser or in the case the search engines testing “browser”, naturally faster is better, and ways to improve would be to reduce the overall payload site and optimize the network request, and in some cases more is less.

A modern browser can handle numerous network requests, between tens and even hundreds so lots of small, cachable files can be more beneficial than a single bundle file, JS devs will remember the vendeor.js file.

In the case of Flutter for the web, the payload is still pretty large, after Flutter 2 was released I put together a small app to look into null-safety from a clean slate instead of upgrading an existing project.

It was very simple with a single page and a single API call built with riverpod. You can take a look HERE, and the  source code.

The payload size here, for an HTML build, is about 3MB, in React it probably would have been around 400kb if not less, it would be about double the size in a canvas build that downloads a web assembly runtime of about 3MB.

#flutter-web #flutter