pub fn delayed_widget<H: Html>(&self, cx: Scope, path: &str, props: P) -> View<H> {
        self.__widget(cx, path, props, true)
    }
An alternative to `.widget()` that delays the rendering of the widget
until the rest of the page has loaded.

Normally, a widget will have its state generated at the earliest
possible opportunity (e.g. if it only uses build state, it will be
generated at build-time, but one using request state would have to
wait until request-time) and its contents prerendered with the pages
that use it. However, sometimes, you may have a particularly 'heavy'
widget that involves a large amount of state. If you're finding a
certain page is loading a bit slowly due to such a widget, then you
may wish to use `DelayedWidget` instead, which will generate state
as usual, but, when it comes time to actually render the widget in
this page, a placeholder will be inserted, and the whole widget will
only be rendered on the browser-side with an asynchronous fetch of
the state.

Usually, you won't need to delay a widget, and choosing to use this over
`.widget()` should be based on real-world testing.

Note that using other widgets inside a delayed widget will cause those
other widgets to be delayed in this context. Importantly, a widget
that is delayed in one page can be non-delayed in another page:
think of widgets as little modules that are imported into pages.
Delaying is just one importing strategy, by that logic. In fact, one
of the reasons you may wish to delay a widget's load is if it has a
very large nesting of depdendencies, which would slow down
server-side processing (although fetching on the browser-side will
almost always be quite a bit slower). Again, you should
base your choices with delaying on empirical data!
packages/perseus/src/template/widget_component.rs