Grid uses unit name as identifier, so there's no real fix here. UNIT_NAME_UPDATE is very expensive for Grid. Grid2 uses unitid, so will be a lot less impacted by UNIT_NAME_UPDATE spam. In fact, if no indicator is connected to the name status, the event is not even registered.
Assuming you know and understand how secure frames work, and, if you made Player and Target Frame, that should be a correct assumption, you only have a little bit of knowledge missing to be able to have workig raid frames.
There are basically two strategies to create raid frames. PitBull 3 (probably 4 too, but I haven't checked) or oUF will create frames beforehand and only show the one which have a valid unit. They don't need a SecureGroupHeaderTemplate to do that.
The other strategy is to let a SecureGroupHeaderTemplate frame do the creation and layout of your raid frames for you. That is what Grid (and Grid2) does. A SecureGroupHeaderTemplate is a special kind of secure frame, which is controlled through a handful of specific attributes. The template will create and affect units to unit frames as needed by the raid group and will perform the layout as instructed by the attributes you set.
Because it's a secure frame, you can only change its attributes out of combat.
The list of attributes is available from FrameXML's source code here.
"template" is important. You can set your own template using XML or use a default template like SecureUnitButton, and provide an initialization function by setting the frame's "initialConfigFunction" key to a callable object. Note that this is not an attribute of the header :
local f = CreateFrame("Frame", UIParent, nil, "SecurePartyHeaderTemplate")
f.initialConfigFunction = function (unitFrame)
-- Note that you CAN call :SetAttribute() on unitFrame in this function even in combat.