To start with: everything is context.
If you want to look for a bottleneck you will likely measure differently then when you want to show you comply with a contract (SLA).
I assume when you mention tools (as you didn't actually mention any) you mean (free) online services (like Googles Pageinsight or Pingdom) that measure your serving speed. Which is probably fine when developing for only a few pages. But I would advise tools like Jmeter or Gatlin to measure (and load test) your site.
As you seem to want to know if you can deliver what you promise, based on loading speeds, I would suggest to start measuring the overall behaviour of your likely slowest pages. the assumption would be that if they respond within your expectations, the simpler pages will in all likelihood perform similar or faster. You can spot check a few of them.
The way you test this is also dependent on your site. Is there a logical flow that users would follow? Or is it only a lot of semi-independent pages? You can start with only the bare pages and add complexity in traversing through your site to emulate real life behaviour.
But there is more that you need to factor in:
- how many average concurrent users do you expect (according to the SLA)?
- how many users do you expect during spikes?
- which pages will likely get the most visitors at any given moment?
- what types of clients (mobile? desktop? other?)
- is your test environment comparable to the production?
- what specifics are agreed upon in the SLA?
- and so on..
So at one point you think you know what your system can handle.But it may run out of steam.
If you are in production, you measure information (like Paul suggested) that show you the day-to-day, second-to-second operation of the site. And act based on what it tells you.
Most importantly: you wouldn't want to performance test your production site (EVER!) and cripple it while doing it.