[react] implement additional Performance Issues

[cstavitsky]

The React demo currently has Large HTTP Payload and N+1 API call, but doesn't have a number of other new performance issues that have since been added:

• Image decoding on main thread
• HTTP/1.1 Overhead (requirement is having a server that doesn't understand HTTP2)
• Large Render Blocking Asset
• Uncompressed Asset (images, if currently in a GCP bucket, might have to be returned by a server instead)

Luca's thoughts:

Image decoding on main thread
I don’t think this particular performance issue is gonna have a great narrative in our demo app. I actually don’t know if the detectors will match anything in regards to image decoding for the browser SDK and in case you want to introduce something for the node SDK it would probably involve some kind of image upload for which I don’t think the empower plant website is a good fit.
I recommend skipping this performance issue for the demo.

HTTP/1.1 Overhead
I think this is a great issue to showcase in the demo.
I recommend doing the following for this: Find a page with a lot of resources that we can load. Imo the about page is a great contendor for this since we have a bunch of images here - maybe we should even increase the amount of employees on this page a bit so that we’re more likely to run into the performce issue. Next, you need to serve the employee images on a server that only speaks HTTP 1.1. Maybe also make that server slow intentionally. Imo it is fine to run a separate server just for serving these images.
When all of this is set up and the page loads, the page will show the images load very slowly after one another (make sure browser cache is turned off!) and trigger a performance issue like this one. This will also have an effect on certain web vitals (maybe helpful for the web vitals narrative).

Large Render Blocking Asset
For this I recommend serving and loading a very big javascript file (> 1MB) that does nothing except run a loop for 500ms.
This will probably trigger this performance issue.

Uncompressed Asset
Here I just recommend serving a .css file that is very large >1MB on a server that intentionally returns the data very slowly. Additionally the file can’t be compressed and no compression headers can be on the response.
Since all of these require some kind of external assets to be served in a particular way, maybe it makes sense to have a separate service (uninstrumented) to take care of serving these.

[ndmanvar]

we had Uncompressed Asset working at some point.
Looks like it somehow regressed ):

#194

https://github.com/sentry-demos/empower/blob/master/flask/uc_assets/uc_big_file.js

empower/react/src/components/Organization.js

Lines 30 to 37 in 26e230e

	let c_big_script = document.createElement('script');
	c_big_script.async = false;
	c_big_script.src =
	this.props.backend +
	'/uc_assets/uc_big_file.js' +
	'?cacheBuster=' +
	Math.random();
	document.body.appendChild(c_big_script);

[cstavitsky]

Closing in favor of

• [react] uncompressed asset - performance issue #276
• [react] Large render-blocking asset - performance issue #275
• [react] HTTP/1.1 Overhead - performance issue #274

Per Luca's advice, won't do image decoding on main thread. He said:

Image decoding on main thread
I don’t think this particular performance issue is gonna have a great narrative in our demo app. I actually don’t know if the detectors will match anything in regards to image decoding for the browser SDK and in case you want to introduce something for the node SDK it would probably involve some kind of image upload for which I don’t think the empower plant website is a good fit.
I recommend skipping this performance issue for the demo.