You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: modules/ROOT/pages/prerender.adoc
+74-73Lines changed: 74 additions & 73 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,35 +10,57 @@
10
10
11
11
The following diagrams illustrate how ThoughtSpot embed components load in a typical application, both for normal and pre-rendered scenarios. Reviewing these will help set the context for the strategies described in this guide.
When a ThoughtSpot embed loads, it goes through several distinct phases:
16
+
17
+
image::./images/pre-render/dig1.1.png[]
18
+
19
+
In the diagram above, each block represents a step in the embed loading process, and each block takes time to complete. The ThoughtSpot embed loading process consists of:
20
+
21
+
1. **Host App Load** - Your application initializes and loads
22
+
2. **Init** - ThoughtSpot SDK initialization and login.
23
+
3. **ThoughtSpot Embed Loads** - The load time taken for the embed to load.
24
+
25
+
image::./images/pre-render/dig1.2.png[]
26
+
27
+
As shown in the detailed diagram above, each block represents a distinct step that takes time to execute. The ThoughtSpot embed load process can be further broken down into the following phases:
* **Common Bootstrap** – Setting up the basic embed framework
31
+
* **Embed Level Asset Load** – Loading specific assets for the embed type
32
+
* **Embed API Calls** – Fetching data and rendering the content
17
33
18
-
When you embed ThoughtSpot (or any analytics app) in your application, the typical flow is:
34
+
=== Optimized Load Flow with Early Init
35
+
36
+
For applications that have a loading screen or home page before the liveboard embed, you can optimize performance by calling init in parallel:
37
+
38
+
image::./images/pre-render/dig2.png[]
39
+
40
+
This diagram shows how you can start the authentication/login process early by calling init while the end user is still on the home page or loading screen. Note that this only handles the login process in parallel - no assets are loaded during this phase.
41
+
42
+
== How Embedding Normally Works (The Basics)
19
43
20
-
. The user navigates to a page with the embed component.
21
-
. The embed component is rendered in the DOM.
22
-
. The browser loads the ThoughtSpot iframe and all required assets (JS, CSS, etc).
23
-
. The iframe initializes, fetches data, and finally displays the analytics.
44
+
When you embed ThoughtSpot in your application, the typical flow is:
24
45
25
-
This means *every time* a user visits the page, the iframe and all assets are loaded from scratch, causing a visible delay before analytics appear.
46
+
. Call init (authentication/SDK initialization)
47
+
. Render the embed component
48
+
. Embed loads the iframe
49
+
. Iframe loads assets, calls APIs, and shows the analytics
26
50
27
-
image::./images/pre-render/embed_load.png[]
51
+
This means *every time* an end user visits the page, the iframe and all assets are loaded from scratch, causing a visible delay before analytics appear.
28
52
29
53
== What is Pre-rendering?
30
54
31
-
Pre-rendering changes this flow by *loading some or all of the assets and initialization steps in the background*, before the user actually navigates to the analytics. This way, when the user visits the page, the analytics are ready to show instantly (or much faster).
55
+
Pre-rendering changes this flow by *loading some or all of the assets and initialization steps in the background*, before the end user actually navigates to the analytics. This way, when the end user visits the page, the analytics are ready to show instantly (or much faster).
56
+
57
+
You can preload just the common assets, or even a specific liveboard, depending on your needs. This doc explains the different pre-render strategies, when to use each, and how to implement them in React or JavaScript.
32
58
33
59
[NOTE]
34
60
====
35
-
Pre-rendering is most effective when your application has a loading page, landing page, or pre-embed page where you can start the pre-render process before the user navigates to the analytics. If a user navigates directly to the embed page (for example, via a direct link or bookmark), pre-rendering cannot provide a speed benefit because there is no opportunity to load assets in advance.
61
+
Pre-rendering is most effective when your application has a loading page, landing page, or pre-embed page where you can start the pre-render process before the end user navigates to the analytics. If an end user navigates directly to the embed page (for example, via a direct link or bookmark), pre-rendering cannot provide a speed benefit because there is no opportunity to load assets in advance.
36
62
====
37
63
38
-
Pre-rendering can preload just the common assets, or even a specific liveboard, depending on your needs. The rest of this doc explains the different strategies and how to use them.
39
-
40
-
Pre-rendering lets you load ThoughtSpot embed components in the background, so users see analytics instantly when they navigate to them. This doc explains the different pre-render strategies, when to use each, and how to implement them in React or JavaScript.
41
-
42
64
== Why Pre-render?
43
65
44
66
* Reduce wait times for embedded analytics
@@ -51,9 +73,11 @@ Pre-rendering lets you load ThoughtSpot embed components in the background, so u
51
73
52
74
- Fully loads the embed iframe, including all assets and liveboard data, as soon as the component is rendered.
53
75
- Fastest experience for a specific liveboard.
54
-
- Maximum resource usage if the user never views the embed.
76
+
- Maximum resource usage if the end user never views the embed.
55
77
56
-
To use this strategy, place the following component on your application's home page, loading page, or landing page (before the user navigates to the analytics):
To use this strategy, place the following component on your application's home page, loading page, or landing page (before the end user navigates to the analytics):
57
81
58
82
[source,jsx]
59
83
----
@@ -70,30 +94,26 @@ The value of `preRenderId` can be any string, but it must match the `preRenderId
70
94
Limitation: Any props you want to pass to the embed (such as configuration options) must be passed to the `PreRenderedLiveboardEmbed` component on the home page. If you later render a `LiveboardEmbed` with the same `preRenderId`, those new props will not be respected if the iframe is already loaded. This is a current limitation of the pre-rendering approach.
71
95
====
72
96
73
-
[example]
97
+
When you actually want to show the liveboard, call this component:
98
+
99
+
[source,jsx]
74
100
----
75
-
// React example
76
-
import { LiveboardEmbed } from "@thoughtspot/visual-embed-sdk/react";
- Defers liveboard-specific data/API calls until needed.
93
111
- Keeps the app ready, making the first liveboard load faster.
94
-
- Still loads some assets even if the user never opens the embed.
112
+
- Still loads some assets even if the end user never opens the embed.
95
113
96
-
To use this strategy, place the following component on your application's home page, loading page, or landing page:
114
+
image::./images/pre-render/dig4_wo_livid.png[]
115
+
116
+
To use this strategy, place the following component on your application's home page, loading page, or landing page (before the end user navigates to the analytics):
97
117
98
118
[source,jsx]
99
119
----
@@ -102,82 +122,65 @@ To use this strategy, place the following component on your application's home p
102
122
/>
103
123
----
104
124
105
-
Again, the value of `preRenderId` can be any string, but it must match the `preRenderId` you use when rendering the actual embed later.
125
+
The value of `preRenderId` can be any string, but it must match the `preRenderId` you use when rendering the actual embed later.
106
126
107
127
[NOTE]
108
128
====
109
129
Limitation: Any props you want to pass to the embed must be passed to the `PreRenderedLiveboardEmbed` component on the home page. If you later render a `LiveboardEmbed` with the same `preRenderId`, those new props will not be respected if the iframe is already loaded.
110
130
====
111
131
112
-
[example]
132
+
When you actually want to show the liveboard, call this component:
133
+
134
+
[source,jsx]
113
135
----
114
-
// React example
115
-
import { LiveboardEmbed } from "@thoughtspot/visual-embed-sdk/react";
- Loads nothing up front; the embed is loaded only when the user navigates to it.
144
+
- Loads nothing up front; the embed is loaded only when the end user navigates to it.
131
145
- On first visit, the embed loads normally; on return, the iframe is reused and appears instantly.
132
146
- Most efficient; only loads if needed, and reuses the iframe for instant reloads.
133
147
148
+
image::./images/pre-render/dig5_ondemand.png[]
149
+
134
150
When you render a component with a `preRenderId` for the first time, it loads as usual. The next time you render a component with the same `preRenderId`, the load is instant because the iframe is reused.
135
151
136
152
This strategy does not require special configuration—simply pass a `preRenderId` prop to your normal component render:
- Loads a few common JS/CSS assets in parallel with your app.
174
175
- No liveboard data or API calls are made.
175
176
- Minimal benefit (modern browsers cache these assets anyway).
176
-
- Wastes bandwidth if the user never opens the embed.
177
+
- Wastes bandwidth if the end user never opens the embed.
178
+
179
+
image::./images/pre-render/dig6_prefetch.png[]
177
180
178
181
[NOTE]
179
182
====
180
-
Prefetch is generally not recommended unless you have a specific need, as modern browsers already cache static assets efficiently. Using prefetch may result in unnecessary network usage without significant performance gain.
183
+
As modern browsers already cache static assets efficiently, using prefetch may not provide a significant performance gain.
0 commit comments