One measurement or two

The two lines everybody writes

float celsius  = sht.readTemperature();
float humidity = sht.readHumidity();
Serial.print(celsius); Serial.print(" C  ");
Serial.print(humidity); Serial.println(" %");

That is correct code. It compiles, it prints two sensible numbers, and it does twice as much work as it needed to.

What is actually in the library

Both functions do the same thing:

float Adafruit_SHT31::readTemperature(void) {
  if (!readTempHum()) return NAN;
  return temp;
}

float Adafruit_SHT31::readHumidity(void) {
  if (!readTempHum()) return NAN;
  return humidity;
}

And readTempHum() sends the measure command, waits 20 ms, reads six bytes and checks both checksums — every time it is called. There is no cache. There is no timestamp. Nothing anywhere in the class asks "have I just done this?".

So two calls is two commands, two twenty-millisecond waits and two sets of six bytes: about 42 ms of blocked sketch where 21 would have done, and twice the energy per reading.

Twenty milliseconds is nothing to a room, so the two numbers are not meaningfully out of step with each other. The cost is the time and the energy — and the tidiness of a reading that is one measurement rather than two.

The call that does it once

float celsius, humidity;
if (sht.readBoth(&celsius, &humidity)) {
  Serial.print(celsius); Serial.print(" C  ");
  Serial.print(humidity); Serial.println(" %");
}

One measurement, both numbers, and a bool instead of two NaNs to test for. It is half the time, half the energy, and one fewer thing to reason about when something downstream combines the two values — a dew point, a comfort index, an absolute humidity in grams per cubic metre all assume the temperature and the humidity describe the same air.

Why this is a trap rather than a quirk

Because the habit is correct next door.

Adafruit's DHT library, by the same author, with the same shape of API, caches for two seconds: #define MIN_INTERVAL 2000, and a read inside that window returns the previous result without touching the wire. So on a DHT22, calling readTemperature() and then readHumidity() is one exchange and the right thing to do.

Move to the SHT31 and the identical two lines are two exchanges. Nothing in either library's documentation puts those two facts next to each other, and neither produces an error. You get right-looking numbers and a loop that is twice as slow as it should be.

The general lesson is duller and more useful than the specific one: when a library gives you two getters for two things that arrive together, find out whether calling both costs one fetch or two. Reading the source is usually quicker than guessing.

And put it on a timer

While you are here, the delay(2000) in the first reading is fine for a sketch that only prints and wrong for one that does anything else. The sensor has no minimum interval to respect — unlike a DHT, which refuses to answer inside one or two seconds — so read it as often as your project needs, and use a millis() timestamp rather than stopping the whole sketch:

unsigned long lastRead = 0;

void loop() {
  if (millis() - lastRead >= 2000) {
    lastRead = millis();
    // ... readBoth, print
  }
  // and everything else your sketch does, still running
}