Because I am still concerned about performance, I want to investigate whether I can replace my raycasts for colliders.
I was thinking about thin, long box colliders in the form of triggers. I could then set for example this.contact to true on collisionstart and false on collisionend. However, I foresee problems when another obstacle already has been hit at that moment.
How can I best tackle this, or should I keep the raycasts?
What kind of bodies do you expect to collide with your colliders? Box, spheres and/or meshes etc.
In general if you are asking about performance, I’d not say that would be faster or anything since it will still go through Ammo.js.
All possible colliders. Is there any difference?
And when I’m using for example 15 raycasts in the update on the player, and also on every enemy? 
Well, if you were able to use only box or sphere for colliders you could do raycasts/collisions using the pc.BoundingBox or pc.BoundingSphere classes.
Potentially you could get a performance increase if you handle your collision lists properly, but this can be complex to implement.
Yeah, that’s a lot of raycasts! To be honest, I am not sure what to propose. Since you are basically scanning the environment on realtime per frame, pathfinding raycasts seem the way to go.
Colliders may work depending on your environment but I am not sure you will get better performance with that.
What I’d suggest with your raycasts is to try running them less frequently. Instead of running them per frame, run them 7-8 times per second and see if you still get acceptable precision out of this.
I also mentioned earlier probably (or maybe I diidn’t… 
) but you could optimize your game by avoiding the raycast updates in real-time, e.g. per frame. Pretty much as @Leonidas suggested. I would probably create some very simple path finder which will be able to create a short path for the unit to follow. So, while the unit is following the path, he doesn’t need any raycasts, since the path is safe. If you make a path long enough, your raycasts could be used to update the path only once in several seconds, when the unit reaches its end.
I am afraid that updating the raycast less often will ensure that enemies do not respond to obstacles in time, causing unnatural movements or disappearing in obstacles.
The raycasts were created because I am not smart enough to make a real-time pathfinding.
Well, your current setup is more complex than a simple pathfinder You don’t need a fancy pathfinder with lots of features. Simply fire a ray or a few in some directions - pick the one with a longest length and make the unit go to that point. There - simple pathfinder.
Isn’t that what I do now?
Exactly! I guess, what I am trying to say is that don’t be afraid to write a pathfinder - you already have one! And the current one is quite sophisticated, even So, you don’t need to write a new pathfinder - you just need to make the current one simpler.
A pathfinder is simply a script that helps your units to navigate around the map. Your goal is probably to find a way for your current pathfinder to still allow your units to move around, but would not require it to probe the surroundings every frame.
For me, pathfinding is a function that knows the best route before the unit moves and I don’t have that.