Coroutines are not laggy, nor is spawn. Spawn is lower-frequency than coroutine since it runs on the Roblox scheduler, but to my experience neither of them are laggy.
Weak tables prevent lag. What they contain is to be garbage-collected when data isn’t apparent / accessable.
ModuleScripts are not laggy in the slightest. They’re just glorified functions.
PCall is not laggy, period.
Statically-typed Luau syntax I can’t say for.
Delay isn’t laggy.
Large scripts are bound to be laggier because they’re going to be running more compared to a smaller script. It’s kinda obvious.
Instance connections aren’t laggy.
Why would you ever use a JSON encoded string instead of decoding it? I can’t imagine a use case for that at all.
Seems to me like it’s laggy in excession.
You shouldn’t need to use a custom raycast function, nine times out of ten it’s probably going to be worse than the one Roblox has now.
See my explanation for Figure 2.
Constraints are bound to have a performance impact due to the physics calculations.
Tween:Create():Play() isn’t laggy. Creating the same tween over and over again and playing it however, is laggy.
SetPrimaryPartCFrame is worse than PrimaryPart.CFrame due to floating point errors, I believe. Correct me if I’m wrong.
I haven’t a clue what that property is.
Anonymous tables aren’t bad. If anything, binding them to a variable per use would be laggier due to the binding overhead.
Instance.new(, parent) isn’t the laggy thing, if memory serves correctly. What is laggy is doing procedures like repositioning or resizing while the object is visible within the workspace (or viewport, depends on how roblox renders).
Is this even a question? Of course that’ll be laggy.
You shouldn’t ever have to do that because server maps will always replicate to the client. The client would always have to render both.
Overall, everything is laggy in excession. Remember DRY. Have common sense. Run benchmarks. All that jazz. Generally, just be smart.