We do not have examples with Blazor, but if you open the C# examples solution, you will see that there are multiple simple Web-based example in other (older) Microsoft Web technologies. The principle, however, remain the same, and I do not expect problems.
QuickOPC is designed with this kind of usage in mind.
One thing that helps here is that QuickOPC automatically manages connections. Let's say you will need to do an OPC read inside the Web request. And such requests are coming in randomly. You can simply make the read call inside your handler, and QuickOPC will take care of opening the connection when it is not currently open, and closing it *after some time* when it is no longer in use. This way, requests that come in close sequence will not cause unnecessary OPC connects/disconnects, which are quite costly performance-wise.
OPC calls that are made to each target server will be serialized by QuickOPC.
You can either instantiate an instance of EasyXXClient for each request handling, OR you can use used a shared instance (if the parameters needed on the instance are the same across the requests, which probably they are). For heavier usage, one instance would be preferable, because creating and destroying the instances also consumes resources. But in the terms of connection handling described above, the effects would be the same, because the instances perform their work using a shared "engine" anyway (unless you set Isolated = true on the instance, which you probably do not want to do).
If you need OPC subscriptions, then obviously you cannot have a subscription inside a short-lived Web request handling. In such case you really need a "shared" EasyXXClient instance, make a subscription on it, and then design a mechanism in which the data will be passed to/from the actual requests.
I hope this helps