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
+63-51Lines changed: 63 additions & 51 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,57 +1,59 @@
1
-
= Pre-rendering ThoughtSpot Embed Components
1
+
= Pre-render ThoughtSpot Embed Components
2
2
:toc: true
3
3
:toclevels: 3
4
4
5
5
:page-title: Pre-rendering for Fast Embeds
6
6
:page-pageid: prerender
7
7
:page-description: How to use pre-rendering to optimize performance and user experience in ThoughtSpot embedding
8
8
9
-
== Load Flow Diagrams
9
+
This document explains the different pre-render strategies, when to use each, and how to implement them in React or JavaScript.
10
+
11
+
== Load flow of embed
10
12
11
13
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 you embed ThoughtSpot (or any analytics app) in your application, the typical flow is:
20
+
When you embed ThoughtSpot in your application, the typical flow is:
19
21
20
22
. 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.
23
+
. The embed component is rendered in the Document Object Model (DOM).
24
+
. The browser loads the ThoughtSpot iframe and all required assets, such as JS, CSS, and so on.
25
+
. The iframe initializes, fetches data, and finally displays the analytics content.
24
26
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.
27
+
This means that *every time* a user visits the page, the iframe and all assets are loaded from scratch, resulting in a noticeable delay before the analytics appear.
26
28
27
29
image::./images/pre-render/embed_load.png[]
28
30
29
-
== What is Pre-rendering?
31
+
== What is pre-rendering?
30
32
31
33
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).
32
34
33
35
[NOTE]
34
36
====
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.
37
+
Pre-rendering is most effective when your application includes a loading page, landing page, or pre-embed page. These pages allow you to initiate the pre-rendering process before the user navigates to the embedded content. However, if a user goes directly to the embed page, by either clicking a direct link or using a bookmark, pre-rendering will not provide any advantage in terms of loading speed, because there is no opportunity to load assets in advance.
36
38
====
37
39
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.
40
+
Pre-rendering can preload just the common assets, or even a specific Liveboard, depending on your needs. It lets you load ThoughtSpot embed components in the background, so users see analytics instantly when they navigate to them. The rest of this document explains different strategies and how to use them.
41
41
42
-
== Why Pre-render?
42
+
== Why pre-render?
43
+
Pre-rendering offers the following advantages:
43
44
44
45
* Reduce wait times for embedded analytics
45
46
* Improve perceived performance and user experience
46
47
* Choose the right tradeoff between speed and resource usage
47
48
48
-
== Embed Load Strategies
49
+
== Embed load strategies
49
50
50
-
=== 1. Prerender with Liveboard ID
51
+
=== Pre-render with Liveboard ID
51
52
52
-
- Fully loads the embed iframe, including all assets and liveboard data, as soon as the component is rendered.
53
-
- Fastest experience for a specific liveboard.
54
-
- Maximum resource usage if the user never views the embed.
53
+
This method allows you to:
54
+
- fully load the embed iframe, including all assets and Liveboard data, as soon as the component is rendered.
55
+
- provide the fastest access to the specified Liveboard.
56
+
- allow maximum resource usage if the user never views the embed.
55
57
56
58
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):
57
59
@@ -65,12 +67,12 @@ To use this strategy, place the following component on your application's home p
65
67
66
68
The value of `preRenderId` can be any string, but it must match the `preRenderId` you use when rendering the actual embed later.
67
69
68
-
[NOTE]
70
+
[IMPORTANT]
69
71
====
70
-
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.
72
+
If you want to pass props such as configuration options to the embed, note that these props must be passed to the `PreRenderedLiveboardEmbed` component on the homepage. If you later render a `LiveboardEmbed` with the same `preRenderId` after the iframe has loaded, the new props will not be applied. This is a known limitation of the pre-rendering approach.
71
73
====
72
74
73
-
[example]
75
+
[source,typescript]
74
76
----
75
77
// React example
76
78
import { LiveboardEmbed } from "@thoughtspot/visual-embed-sdk/react";
- Defers liveboard-specific data/API calls until needed.
93
-
- Keeps the app ready, making the first liveboard load faster.
94
+
- Loads common assets and bootstrap logic early
95
+
- Defers Liveboard-specific data/API calls until needed.
96
+
- Keeps the app ready, making the first Liveboard load faster.
94
97
- Still loads some assets even if the user never opens the embed.
95
98
96
99
To use this strategy, place the following component on your application's home page, loading page, or landing page:
@@ -104,12 +107,15 @@ To use this strategy, place the following component on your application's home p
104
107
105
108
Again, the value of `preRenderId` can be any string, but it must match the `preRenderId` you use when rendering the actual embed later.
106
109
107
-
[NOTE]
110
+
[IMPORTANT]
108
111
====
109
112
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.
113
+
114
+
If you want to pass props such as configuration options to the embed, note that these props must be passed to the `PreRenderedLiveboardEmbed` component on the homepage. If you later render a `LiveboardEmbed` with the same `preRenderId` after the iframe has loaded, the new props will not be applied. This is a known limitation of the pre-rendering approach.
115
+
110
116
====
111
117
112
-
[example]
118
+
[source,typescript]
113
119
----
114
120
// React example
115
121
import { LiveboardEmbed } from "@thoughtspot/visual-embed-sdk/react";
- Loads nothing up front; the embed is loaded only when the user navigates to it.
131
-
- On first visit, the embed loads normally; on return, the iframe is reused and appears instantly.
132
-
- Most efficient; only loads if needed, and reuses the iframe for instant reloads.
136
+
This method offers the following advantages:
137
+
138
+
* It does not load anything upfront; the embed is only loaded when the user navigates to it.
139
+
- On the first visit, the embed loads normally. On subsequent visits, the iframe is reused and appears instantly.
140
+
- It is highly efficient, as it only loads when needed and reuses the iframe for instant reloads.
133
141
134
142
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
143
136
-
This strategy does not require special configuration—simply pass a `preRenderId` prop to your normal component render:
144
+
This strategy does not require special configuration. Just pass a `preRenderId` prop to your normal component render:
- Loads a few common JS/CSS assets in parallel with your app.
174
-
- No liveboard data or API calls are made.
175
-
- Minimal benefit (modern browsers cache these assets anyway).
176
-
- Wastes bandwidth if the user never opens the embed.
184
+
- Does not show Liveboard data or makes API calls
185
+
- Offers minimal benefit because modern browsers cache these assets anyway
186
+
- Results in unnecessary bandwidth consumption if the user never accesses the embedded content
187
+
177
188
178
189
[NOTE]
179
190
====
180
191
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.
181
192
====
182
193
183
-
.Example: Prefetching assets
184
-
[source,js]
194
+
The following example shows how to prefetch assets:
0 commit comments