We usually break by feature, so the decomposition you've described seems valid.
Just note:
Content pages would potentially be just "content page", where the actual content comes from a headless CMS or other content delivery service
The navigation would not be a dedicated microfrontend but rather be distributed among all microfrontends (each one could decide what to deliver to the navigation); the mentioned product detail page would either be part of the "product experience" microfrontend or in its own (depending on the business context and team structure)
The home page would potentially be centralized, however, its content distributed like the navigation; e.g., the recommendation microfrontend team could provide a sneak peak of their best recommendations for you on the home page
While some features would certainly be contained in dedicated or even "stand alone" pages, many features would just be scattered and recomposed.
But that's just our take - any decomposition is valid if done with the right reasoning.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I love the idea of micro frontends. The perks you mention are exactly why we were going to break up our FE at my last company.
Where do you decide to breakup monolith frontends though?
Let’s use an e-commerce site for an example, say Amazon.
I would break out:
I have a hard time determining what is “too many” different front ends.
We usually break by feature, so the decomposition you've described seems valid.
Just note:
While some features would certainly be contained in dedicated or even "stand alone" pages, many features would just be scattered and recomposed.
But that's just our take - any decomposition is valid if done with the right reasoning.