Are these network data client upload/download stats fine for my game (FPS/semi-fast paced)?

So I was a bit worried about my game network usage since im not that experienced in networks. The game itself runs fine, including tests with another remote player with little networking errors position, bullet spread and all seem to coincide fine in client/server but I feared my netcode my be "rough" or bit unoptimized. I now explain in a detailed long way how I send data so if you just want to see the results of network tests, skip to the next section.

I use Forge for the networking.


How I send data from client to server
clients send one rpc/message to the server each fixed time step (60 per sec) with several attributes:
-one vector2 with axis of main movement
-one byte representing the states of jump and crouch key (different combinations)
-one vector3 with position of camera
-one vector3 with the direction player is looking at (these last two allowed us to make aim direction and shooting be deterministic across all clients, taking into account camera position and rotation deviation from screen shakes and others, also allows for extremely fluid and precise player "look at" aesthetic appearance)
-one vector3 with the final/expected position after the input is applied (REMOVED)
-one vector 2 that marks overriden movement applied to the main input axis (player drugged/possessed)
-one vector 3 with a total of the external forces applied to the player (for example using a dash ability, being launched by a jump pad...)(REMOVED)
-one vector 2 with the player mouse raw axis (this is mostly for aesthetic purposes on displaying on all client inertia on FPerson animations)

This one gets sent from client as an unreliable RPC to the server, both client and server run this the same, and if server gets a different result from "expected position" received from client, server sends back a correction. The code to run the movement calculates the movement trough delta time on both sides and thus far, has been fine. I think that by switching the server to take the diference between last rpc timestap and current rpc timestamp instead of deltatime I may be able to get rid of the external forces vector3 and the "possession" vector 2, as those 2 are the most prone to deltatime error if they were run independantly with just a start condition instead of updated trough this method.

Then, on a much lower rate (around 6 times per second) several stats may be updated (status conditions, and other things, they are a lot of states but they are change very infrequently, and only updated if they change). This is done trough stream.

At last, players can perform actions or use items. Interacting with an inworld object just sends one value: the keystroke used to interact with it as a string. Using an item (main thing in the game) uses the following values in an RPC:
-one byte to store the id of the user
-one string with the id of the item to be used
-one vector3 with the player camera position
-one vector 3 with the player aim direction
-one int with a seed
-one byte with an additional value/seed (those last 4 things send allow for deterministic hits/spread/usage results)
-one byte to set firing/usage mode (many items have alternative fire/use)
-two floats with charge values (many items have "hold to charge" firemodes)
-one byte that tells if its an item use started by the server of player, making the local player use the item if this is a server-authority started item use.

I tried to send as little as possible over the net, there are actual a metric ton of stats, variables and things


The results in data usage with windows network resource manager and comparison with official popular game
So far this way of doing things allowed me to have deterministic results across clients and zero cheat capability if we don't count aimbots, we tried cheats of firerate, teleport, godmode, instakills... and nothing works. Now to the important part. I monitored the server and client running, specially the client, since I seem to send many values to the server 60 times per second, instead of being more "tidy" like packing inputs across several fixedtimestep frames and sending them less frequently or something.

The client averages around 8000-9000 B/s of send rate in windows resource manager while running around, interacting with doors and opening boxes and firing a machinegun item that fires 15 times per second, and around 6000-7000 when strolling around more idly.

I opened modern warfare and played some games, checking with the resource manager the ip opened by the game when connected to a game server, running around with a similar firerate weapon as the machinegun used in my game, and I seem to average a similar client send rate, varying slighly with the map it seems. Behaviors also were similar, with send rate being lower if I didnt fire my weapon around and strolled more idly, suggesting that this game also uses separate messages for shooting weapons instead of packing everything in the base input. Overall a very similar result in the resource manager, with my game kinda mimicking how modern warfare behaved send rate wise. I did not use voice chat in modern warfare.

Should I bother optimizing more and trying to tidy up and get rid the mentioned values I could try to get rid of? Is the network resource manager a good way to measure this and does both my game and modern warfare client showing similar results depict a reliable way of knowing if I have a good client send rate data usage? Also, does it make a difference if im hosting the server myself in the same computer? I connect trough my own server via matchmaking, using my external ip and port for the connection.

Sorry for the long post but I hope the detailed explanation helps with the answers

EDIT: Just checked Valorant (new Riot shooter): opened up the tutorial/practice, it opened a connection to an ip (which answered another question I had: if multiplayer shooters do things locally for tutorial/practice areas, but it seems that everything runs on servers even when you open the tutorial for the first time in game it seems, it uses a remote server to do it. Its kind of a relief, as it seems I don't have to code a mockup client hosted server for the tutorial in my game. Then again it opens another topic: How does it affect server costs that any client can request an entire game lobby just for them only?. I could open a custom game/tutorial area and leave the game sitting there all day).

valorant averaged around 11000 B/s with some variation shooting around in the tutorial area. Also similar behavior or B/s increasing when shooting than when just walking


UPDATE: Was able to remove the greyed out things by predicting them client side and helping choose what to correct trough a tick-based history. Now the client averages 6000-7000 B/s sendrate while firing fast firerate weapons all the time, which formely was the "idle" score. I'll se if I can strip more values!