Mmmh DOCSIS ISP have a tendency to promise less than they actually provision. So in your case O probably would set the download shaper to 100-110 Mbps (download shaping is approximate and a bit of head space to the real bottleneck is recommended), for egress I would try 30. And then confirm that these settings deliver acceptable bufferbloat under load 
If it's bad they only promise 10%, that's what they told me
That really depends on the number of users in your segment and how many are active concurrently. Almost all access networks offer more aggregate enduser-capacity than the network can deliver (under worst case all are active at the same time assumptions), but the actual situation is rare.
However if this happens often in your network, have a look at https://forum.openwrt.org/t/cake-w-adaptive-bandwidth/108848 how to adaptively adjust the cake shaper settings.
It seems that I should reduce something more
Why, the test looks fine...
noticed there was an increase in load
another question how to know if my isp uses vlan? or is there any way?
In that test you posted a link to? What do you mean by "load" here?
Ask them? Other than that I have no robust and reliable method to offer. As I hinted at, measuring the throughput at different MSS can in theory help to deduce the per-packet-overhead, but requires really precise and repeatable measurements of the throughput; which makes this a rather theoretical Gedankenexperiment more than a useful empirical method.
to the upload link
But what happened to the upload? Too little thoughput/speed or too high bufferbloat?
the latency went up a bit but not so much as to despair maybe it's because I put overhead 22 I'll try with 18
Well, the way sqm's main work horses, fq_codel and cake, work is that by default they allow a standing queue of up to 5ms (or rather if the queuing duration of a flow exceeds 5ms for more than 100ms a drop/mark gets scheduled); the upshot of this is that during saturating loads the latency increases by at least 5ms...
When I compare the 95%iles of your tests between idle and down and upload I see only one value significantly exceeding 5ms, so from my perspective this is as good as it can be confirmed with on-line speedtests.
However you can always try to repeat the test with the shaper set to 50% of the current values, if the latency under load gets significantly smaller compared to your 100% tests, then we can continue the discussion
If this is reliably better (in your opinion, this is a policy decision you need to take how much latency under load you are willing to accept, knowing that 0 is not really possible) start from there and slowly increase the shaper rate under speedtest control until you reach a point where you get uncomfortable with the evoked latency.
Keep in mind though that such measurements especially with a browser have some random variability, so repeat the speedtests at each shaper settings a few times to confirm they are reliable.
with sqm activated?
Yes, with SQM enabled.