The mental model that fixed this for us: a preview is a unit test with a screen. Everything true of a hard-to-test view is true of a hard-to-preview one, and the remedy is the same.
Which means the view should take its data as a value, not fetch it. If a view constructs its own view model that opens a connection, the preview has to make that work, and it either fails or hangs. If the view takes already-loaded state as a parameter, the preview passes it a literal and there is nothing to fail.
In practice that means splitting most screens into two: a dumb view that takes state and emits events, and a thin container that wires it to real data. Preview the dumb one. It renders instantly because it depends on nothing, and as a bonus you can preview all its states — empty, loading, error, long text — which you could never do against a live data source.
That last point is worth more than the speed. Most of the value people get from previews is seeing the awkward states, and a preview wired to a real backend only ever shows you the happy path.
This is the same split that makes the view testable, so it is not extra work invented for the tooling. If the previews are hard, the tests are hard too, and you probably have fewer of them than you would like.