A junior tester on my team spent a morning on a failing test. The error said the element was not found. The element was on the screen. She could see it.
The page had loaded, but the list was still being fetched from the server. The screen she was looking at was two seconds older than the moment the test looked. Knowing the pieces would have saved her the morning.
Here are the pieces.
The browser is the program the user runs: Chrome, Firefox, Safari. It asks for pages and draws them.
The server is a program on a machine somewhere that answers those requests. It holds the data.
A request is the browser asking the server for something. "Give me the contacts list." "Save this new contact."
A response is the server's answer. Usually the data, plus a status code, a number that says how it went. 200 means fine. 404 means not found. 500 means the server broke.
Now the three things a page is built from.
HTML is the structure and the content. It is a set of nested tags:
<button class="primary" data-testid="save-contact">Save</button>
That is one element. button is the tag, class and data-testid are attributes, extra information attached to the element, and Save is the text a user reads. Your tests find elements using exactly these pieces.
CSS is the appearance. Colour, size, position, and whether something is visible at all. CSS matters to you more than it looks: an element can exist in the HTML but be invisible because of a CSS rule, and most frameworks refuse to click what a user could not see.
JavaScript is the behaviour. It runs inside the browser, reacts to clicks, sends requests to the server, and changes the page after it has loaded.
That last point is the one that causes most test failures, so read it slowly.
The page you see is not the page that arrived. In a modern app, the browser first receives a mostly empty page. Then JavaScript runs, asks the server for data, waits for the answer, and puts the results on screen. That can take a few hundred milliseconds, or a few seconds on a slow connection.
So there is a window of time where the page has "loaded" but the content is not there yet. Your test, which runs in milliseconds, arrives inside that window constantly. This is the root of nearly every timing bug you will meet, and there is a whole lecture on it later in this track.
Remember this: a page arrives in pieces, and your test is fast enough to catch it half-built.
Reference: MDN, how the web works.