Do you have a timeline when you were hoping to launch this?

The plan is basically to deploy it really soon. I can't talk on behalf of WMDE on the final day but it's basically as soon as possible (specially since the security readiness review is done)

You can ;-)
As Amir said, we'd like to deploy the tool as soon as possible.

I'll start with this later this week. One thing you can start with is this:

We don't have ongoing measurement of javascript performance so it might get worse without us noticing.

You can use the User Timing API for that, that would be super helpful if that is added before its used by real users. If you use the API those metrics are automatically picked up by our synthetic measurement tools if we point them to the query builder. If you feel like it you can create your own synthetic test, you can checkout searchWvuiObama.js in https://github.com/wikimedia/performance-synthetic-monitoring-tests/tree/master/tests/desktop how that can be done (I can also help you).

You can also have a look how the team implemented user timings for the Wvui search.

You can also beacon those metrics back to your server from real users, that is good so we can pickup if there are some users that struggle with the performance. Could those tag along with the other metrics you are measuring or are those backend only in your graphs?

Change 712966 had a related patch set uploaded (by Ladsgroup; author: Amir Sarabadani):

[performance/synthetic-monitoring-tests@master] Add query builder

https://gerrit.wikimedia.org/r/712966

Thanks. I started it, the problem is that the URL is not up so we can't merge the patches, I hope I did them correctly at least. Does that look correct to you?

@Ladsgroup I'm thinking maybe a user journey is better to measure instead of a cold hit? Then we can measure every part of it? Let me explain, I think like this:

1. You add user timings that is meaningful to you (like either the full JS execution or parts of it if that could help you in the future).
2. We add user user journey to the synthetic tests: I can do that if you help me with a good journey. That could be like going to the start URL, adding a property(/value and run the query. That way we will automatically collect the user timings but also devtools timeline data for JS where the time is spent. If we do that for one URL/user journey that is good because then we have a history of data so if you do change later on, we have something that we can compare with.

Does that sounds ok @Ladsgroup ?

I want to start with something simple and slowly migrate to something more complex. Specially since basically every interaction's bottleneck is API response time (e.g. for lookup for property ID, loading the WDQS results, etc.) and not the app itself. Other reason is that the main part of the interaction time is just loading the app, the rest are pretty quick.

Cool, I just added a comment to the your push @Ladsgroup !

Change 712966 merged by jenkins-bot:

[performance/synthetic-monitoring-tests@master] Add test for wikidata Query Builder

https://gerrit.wikimedia.org/r/712966

We have it now \o/ https://grafana.wikimedia.org/d/000000282/webpagerelay-drilldown?orgId=1&var-base=sitespeed_io&var-path=desktop&var-testtype=webpagereplay&var-group=query_wikidata_org&var-page=Main_page&var-browser=chrome&var-connectivity=100&var-function=median&var-s3path=https:%2F%2Fsynthetic-tests-result-wikimedia.s3.amazonaws.com

Cool @Ladsgroup, do you have time so I can walk you through the data we collect?

Sure. If you need a call or chat. Feel free to ping me in IRC.

I think this is ok as it is now. I can add a simple alert for the size and then if it fires we can sit-down and have look together.

So it turns out I never added the alert. I can add it now, but who should receive it?

Hi @Lydia_Pintscher, could you help us identify someone that could receive the alerts? Thanks ;)

Yes I can. Can you help me understand again what type of alert we are talking about?

@Lydia_Pintscher I think the main concern from the beginning would be if the JavaScript performance got worse over time and we wanted to add an alert for that. Today when I look at the metric (we measure CPU long tasks https://developer.mozilla.org/en-US/docs/Web/API/Long_Tasks_API) to see JavaScript is blocking the main thread. Looking at the data on that page I could only see one CPU long tasks that is 53 ms, and that is much better than the rest of our performance, so from my point of view I think we can skip it.

Thank you. Taking it with me.

@Peter Thank you for your response. I agree, that can probably skip the alert for now. However, when we resume working on QueryBuilder, we would be in touch in order to set up some kind of way to inform us about degraded JS performance.