Not inherent, and the cause is almost always the same: the module containing the view still depends on most of the app.
A preview builds the view's module and everything that module depends on. If your feature module imports a shared module that imports networking, analytics, the database layer and a dozen others, the preview is compiling most of the app to render one screen. It is slow for the same reason the app is slow to build, and it is fragile because anything failing anywhere in that graph fails the preview.
So the diagnosis is to look at what the module actually pulls in. Draw or dump the dependency graph for one feature module and you will usually find one or two edges doing all the damage — commonly a "core" or "shared" module that has become a dumping ground and now transitively depends on everything.
The fixes, in order of value:
Split the dumping-ground module. It is almost always several unrelated things that ended up together for convenience. This is the big win and it improves build times generally, not just previews.
Depend on protocols, not implementations. The view module should need the interface of your data source, not the module that talks to the network. That single change can cut a preview's dependency graph by most of its size.
Keep the view module free of anything with heavy initialisation. Analytics and database setup in a module's startup path are a common cause of previews that hang rather than fail.