Unless you are a well-programmed robot, you are not going to be able to do the 3D math in your head to know *exactly* where to point your eyeballs out the window to visualize *exactly* where the target you see on your tablet display is in the real world--there's always going to be some slop involved. Given the inaccuracies there, the amount of lag between what you see on your tablet display and where the target actually is at that instant is small enough to be pretty insignificant.
To more directly answer your question, there is some lag, but it is pretty small; on the order of a couple of seconds-ish, max. If you ever fly at an airport with a couple of ADSB-equipped planes in the pattern, you could sit in a benign area for a few minutes and monitor your display as you watch the planes for a couple of circuits to characterize the performance and correlate what you see on the screen with what you see out the window. Note that in that case, you're likely getting your target data directly from the target planes; in cruise, you might be getting some of your data via the FAA's ADSB-rebroadcast. In that case, the signal goes from the target to the ground, where it's received by the ADSB system and processed, then rebroadcast to you, which will add a little bit of lag. I've seen studies that say this latency is less than 1 second, so still pretty negligible.
As for what altitude is reported, it's never reported relative to the ground; it's either the target's altitude above Mean Sea Level or the target's altitude relative to your current altitude, and that's a setting you select within iFly (Menu > Setup > Alerts and Warnings > Traffic Alerts; then check or uncheck "Show Relative Altitudes" as desired).
iFly itself may have multiple options for "your current altitude". GPS altitude is always available and is used by default, but some ADSB devices also provide barometric (pressure) altitude. If baro altitude is available to you, you can choose to use it via Menu > Setup > Units of Measure, and then select "Pressure Altitude Support". (I'm not familiar with the BOM but I'm guessing from your description of "calibrating" it that it must have pressure altitude support, since there's no calibration involved with GPS altitude.)
Note that there can be a lot of "slop" in the relative altitudes too, then: Most ADSB-out setups will be broadcasting altitudes from a pressure altitude encoder (same thing that feeds your Mode C transponder). iFly will be comparing that either to your GPS altitude or to your ADSB device's reported baro altitude, which may be different from the altitude reported by your pressure encoder. Either way, there are opportunities for apples-to-oranges comparisons and other sources of inaccuracy there.
The takeaway from all this is that having ADSB traffic data on a screen is in practice only a little better than ATC calling, "11 o'clock and 3 miles, southbound, altitude indicates 4000 feet". You'll have an idea which direction to point your eyeballs, but you're still going to have to hunt a little bit to find the target in that region of the sky. The best thing about it is that you can continue to reference your display to get updates on how the target is moving while you're trying to visually acquire the target, whereas ATC isn't constantly giving you updated traffic vectors every second.