inheritance vs multiple component for UI

hi, this is mostly a question about performance of the unity event system for UI

i am currently making an effect button class to add various effect like shaking, resize, AnimatedSpriteButton

my current design is
abstract class ButtonEffect : MonoBehaviour , IPointerDownHandler, IPointerEnterHandler, IPointerExitHandler , IPointerUpHandler

this main class deal with most of the basic stuff.

by exemple:

public bool IsActive
		get{return isActive;}
			isActive = value;
	//function called when isActive value is changed from the outside, must be implemented by all child class
	protected abstract void isActiveChanged();

most of the function are virtual and also manage some boolean like isPressed and isInside

then i have a child class like Button resize that use all these function and data to do what it has to do
I can then have multiple different child as different component of different complexity on the same uibutton

by example i have the button spin with these 2 components: ButtonResize : ButtonEffect and ButtonAnimatedSprite : ButtonEffect

each component is independent but here is my question
since each component derive from ButtonEffect, each component OnPointer event function calls will be duplicated and i heard that it is much slower than regular c# event

Should i keep this design or instead change my abstract ButtonEffect for non abstract ButtonEvents and all button effect will instead of inheriting from ButtonEvents will RequireComponent ButtonEvents and subscribe to various event raised by ButtonEvents class.
this way, for each button, all unity OnPointer event will only be called once, then each button effect will subscribe to the event he need

My game is on webgl so optimisation is a must

thank you for your time

The component system is designed for designer-friendly, instead of performance. So Yes, the less components you use, the better performance you have. But i don’t think there is much improvement you can do in UI. Try do the optimisation on game mechanic first.