Attributes vs Remotes - Which is better for networking performance?

I’ve searched all around for an answer and there hasn’t been a clear answer to this question?

Are attributes generally more performant in the case of:

  • Setting an attribute via the server and hooking up a :GetAttributeChangedSignal on the client

Over the standard practice of;

  • Sending a remote event (whether unreliable or reliable) to all clients?

Do remotes have a general networking overhead that makes them slower than roblox’s instance/property replication, or would mass updating attributes cause issues on their own?

All insights appreciated!

1 Like

it really depends on the situation.
I would use attributes for quick, short term signals, mostly small, such as sending a decimal or string or such. But for heavy loading or long term signals, probably just stick with remotes. Not like it matters much but it might also prevent exploiters from using your own client scripts that use the attributes against their original intentions, though its already out there as a client script so it shouldn’t matter too much regarding security

ok i did some benchmarking and for networking, attributes is probably the winner, though roblox struggles with keeping them actively updated compared to that of remotes. it doesnt afflict much onto the network in both cases, and both seem to be just as fast

I feel like this might be a case of optimizing something that doesn’t need to be optimized.

Unless your project is heavily loaded on network streams (which isn’t really advised anyway, as to not bottleneck the server’s resources) I really wouldn’t see any difference in terms of speed.

If you need to process multiple parameters, remotes are the way to go. If you’re checking for individual states or when states are changed, using attributes is probably the winner.

I’ve used both before. Attributes are easier to implement, but remotes are more diverse, customizable, and faster, at the cost of being more complicated to set up.

In general, remotes, especially in conjunction with your own wrappers or organization methods, should be used for long term maintenance. You can always mimick the behavior of attributes with remotes but not the other way around.