Hi and welcome @Cismus!
First a small preliminary note: you don‘t need an extra text component on top of your button; you can write your text directly into the button component and have a picture background at the same time. In the following I‘ll assume that exact scenario.
I‘d guess that the images are more efficient since it is a simple, single layer graphic; basically only transfer pixel data from flash to screen. Text on the other hand involves rendering. And if it‘s text on top of a picture, well, the entire text loading and drawing is additional.
Does it matter? How to measure?
Not sure if what I said above matters (assuming my guess was right); never measured it. But unless you have dozens of buttons with frequent updates on the same page, I‘d say no, doesn‘t matter.
Much more important is that even though images might be faster, they‘re a pain in the a** if you ever need to make any change. I know it because I had an entire UI designed with pictures instead of text. Basically any change to the button (button size, font, font size, color, text) requires you to make a new picture, import it into nextion, replace the old one. Think trice about this before you go for that path.
Now for the measurement itself. In case you haven‘t noticed yet, the debugger/simulator runs so much faster than the actual device that it‘s completely unsuitable for any sort of performance measurements. It also very likely works differently under the hood and thus is not only faster but just not comparable timingwise.
If all you want is the difference between both methods, it is rather simple:
// Press the button
// Not sure whether doevents is needed for getting meaningful measurements but I‘d say yes. doevents processes all changes and draws a fresh image to the screen.
// Release the button
Run this code for both versions of your button and check with a scope, arduino, etc. how long it takes between the two serial messages. If in both cases you get consistent readings (important!) then the difference between the cases must be the time spent on the additional processing in one of the variants.
This only works because everything else is the same and thus cancels out in the comparison. That also means that you can only state that „variant a is x seconds faster than variant b“ but not „a is x percent faster“, because you‘re not measuring how long each variant takes, but how long each variant plus all the stuff around takes. In a difference that doesn‘t matter but in a quotient it does (
(c+a)-(c+b) = (a-b) but
(c+a)/(c+b) != a/b, a,b being the times to draw either button, c being the for-loop, the serial processing, etc.).
What would be required to measure a,b directly? Well, ideally you‘d like to have c=0, a.k.a. nothing else running. But that‘s not possible, so you‘d have to determine c. It gets even worse if c is different in either cases. You could f.ex. just run
Then add the loop. Then the first doevents, then the second, check how the time is scaling with the number of iterations, etc. You could do all this in one step but doing it slice by slice allows you to check each measurement against the others for sanity (f.ex. to catch things like a second doevent being much faster if nothing‘s changed since the previous one; not saying this is the case but you can see how such things could cause false measurements when only removing the two clicks from the example at the top).
This obviously is a deeeep rabbit hole
Edit: while Nextion has timers, too, I‘d not use it to make measurements like these because they run on the same system and nobody knows how they interfere with each other (do they update when a loop is running? When doevents is running? Etc). Hence the serial commands to be able to make a measurement with an independent device.
If it‘s a nextion screen with GPIO pins, one could (and likely should) use those instead of the serial.