Embedded looker Page Load Performance

Looker version: 5.24.16
We have looker embedded(SSO) into our spring boot application in which iframe is loaded with the ember URL as source. We use looker query API(slug) to generate this embed URL.
This is a sample url ‘https://looker-dev.operativeone.com/login/embed/%2Fembed%2Fquery%2FRatingAnalyzer%2Fproduct_nielsen_explore%3Fquery%3DQn4Bhmq?nonce=“vqgg240pobb68tk74tch4ij2dq”&time=1554378397&session_length=3600&external_user_id=“supportops%40o1nbcuni.com”&permissions=[“access_data”%2C"download_with_limit"%2C"see_looks"]&models=[“RatingAnalyzer”]&access_filters={}&signature=47dmieaA2jWMTm0DE3pwTCmqzO0%3D&first_name=“supportops”&last_name=“o1nbcuni.com”&group_ids=[10%2C11]&external_group_id=“o1nbcuni”&user_attributes={+“tenant”%3A+“o1nbcuni”}&force_logout_login=true

While loading the data in iframe, we could get the following metrics for the given parameters.

Total rows: 141
Total columns: 569
Total Page Load: 108,000ms(milliseconds)
Loading 1,823ms
Scripting 34,038ms(Need to understand from looker team)
Rendering 32,120ms(Need to understand from looker team)
Painting 332ms
Other 1,937ms
Idle Time 40,138ms

Observations:

  1. While analyzing the javascript functions getting executed, we could find ‘getClientRects’ function taking 24secs(out of 34secs) to execute.
  2. Digest cycles are getting triggered multiple times during the page load.

Similar times were observed with larger set of rows(3000+) in the report.

Not able to upload the chrome performance report and the javascript profiler info in the ticket. Please let me know. I can share through email.

1 Like

The first thing jumping out at me, separate from any specifics of the javascript, is that you say you’re returning 569 Columns and 141 rows— That’s around 80,000 cells of data, which is definitely pretty high. A general rule of thumb is that browsers start to slow down heavily at ~30,000 cells of data.

Do you see improved runtime with reduced # of columns? That’d be good to know so we can try to improve.

1 Like

Yes, we can see improved performance on reduced columns even with more no. of cells than before but here we are trying achieve a page load of <10seconds for an average report load. Here are few scenarios we tested out.

<—Scenario 1—>
Rows 54
Columns 54

Total Time : 20000ms
Loading : 201ms
Scripting : 9681ms
Rendering : 1541ms
Painting : 156ms
Other : 1170ms
Idle : 8177ms

<—Scenario 2—>
Rows 3154
Columns 54

Total Time : 60000ms
Loading : 115ms
Scripting : 14841ms
Rendering : 3331ms
Painting : 168ms
Other : 1516ms
Idle : 40256ms

<—Scenario 3—>
Rows 1114
Columns 112

Total Time : 58000ms
Loading : 192ms
Scripting : 18211ms
Rendering : 4567ms
Painting : 142ms
Other : 1490ms
Idle : 33416ms

The scripting time does seem to scale up with increased # of rows + columns, specifically columns— Even though scenario 2 has more cells total than scenario 3, it has less time spent rendering and scripting.

Interesting! I wonder what our engineers make of that— I can ask them to drop in on this thread, but I also think that with scenario 2 and 3, that’s pushing the limits of the # of cells the product can render in the web browser.

I know that we have planned improvements for this and are working hard to get those out, so this could be valuable feedback to drive that.

It might be useful for you to visit us at help.looker.com with those logs you mentioned earlier to get a closer look at what’s going on.