Hello GoodData! 👋 I was wondering, is it expected for drilldown to custom URL take much longer than e.g. a drilldown to dashboard? In our case a drilldown to dashboard is instant, but a drilldown to a custom url takes more than a second, which results in a very sluggish user experience. For custom url drilldown, we wait for the

GDC.DASH/EVT.DRILL.DRILL_TO_CUSTOM_URL.RESOLVED

event to get the url and as you can see in the attached screenshot, it comes in more than a second later than

GDC.DASH/EVT.DRILL.DRILL_TO_CUSTOM_URL.REQUESTED

event. We have set up the custom url to something like `https://example.com/{attribute_title(Entity.Entity)}. When I look at the networks tab, I see one request that is probably being awaited before the custom url is resolved, which is a request to

api/v1/entities/workspaces/{workspace}/attributes

. The interesting thing is, that it returns around 200 rows of data, which is absolutely not needed to resolve the url (right?). It seems to me, that no additional request should be necessary in order to resolve the URL. Are we doing something wrong? Thank you!

Hi Tomas, could you please confirm which product you are using? Is this CN, Cloud, or the platform edition? The 200 rows of data don’t seem necessary, but what exactly are you drilling from?

Hi Joseph. It is CN. I’m drilling from a table, clicking on a cell.

Could you also confirm the URL you are directed to after drilling? Is this bringing up another large webpage?

it results in a navigation in our application. the load time of that is not an issue. that starts after

GDC.DASH/EVT.DRILL.DRILL_TO_CUSTOM_URL.RESOLVED

event. the issue is the time between

GDC.DASH/EVT.DRILL.DRILL_TO_CUSTOM_URL.REQUESTED

and

GDC.DASH/EVT.DRILL.DRILL_TO_CUSTOM_URL.RESOLVED

events.

Hi Tomas we are still trying to look into this and will follow up with more details as soon as possible.

great, thanks!!

Hi Tomas, Radek from L2 here 🙂 I've been checking into the actual implementation of the custom URL drilldown, and you're correct in that the slight delay is because of requesting the list of attributes. As far as I can tell, the technical reason for this is that the list of attributes is used to maintain awareness for what can be actually used to drill down into. If you'd like, I can check with the dev team if there are any optimisations possible to implement on your end to speed this up, and come back to you with more info!

Hi Radek! Thanks for the info. That would be very helpful. As a user, when you click a link you’re expecting something to happen right away and waiting for just a second can make it feel very sluggish. The “workaround” could be implementing a loader on the

REQUESTED

event, but I’d like to avoid that, as no additional data are needed to resolve that URL in this case. Even if additional data was needed, we shouldn’t have to download the whole table again. And actually, from what I can see the exact same attributes request is made when the dashboard is loaded.

@Radek Novacek I believe this may be happen in cases when there is a different label used in the drill down URL that the label used in the report (even fro the same attribute). Wouldn't it be possible to download labels used in URLs together with the report? It seems that all other info necessary for drill down should be already available in the report itself and additional query should not be necessary.

Good morning, apologies for the delay 🙂 I've double-checked this, essentially I can confirm that the fetch of attribute data is intended - as per one of our devs:

Unfortunately, the resolving is async function because when you click on a chart we need to resolve alternative label for the attribute item you clicked on and it could take some time.

we need to resolve alternative label

What do you mean by resolving alternative label? At least in our basic use case, there should be no need to fetch any extra data. And even if we needed data from a column that is not displayed in the table, there is no need to fetch data for all hundreds of rows in the table.