Session 10: Debugging & Quality

The developer tools are the single most useful thing in a browser, and most people use a fraction of them. The Elements panel shows the live DOM and the styles applied to whatever you select — including which rule won and which were overridden, struck through. That last part answers 'why is my CSS not applying' faster than anything else.

The Console runs JavaScript and shows errors. An error there is a gift: it names the problem and, usually, the exact line. The Network panel shows every request the page made, how long each took, and what failed — which is how you find a missing image or a request that never returns. The Lighthouse tab runs an automated audit of performance, accessibility and SEO and tells you specifically what to fix.

The habit to build is looking before changing. Most time lost in debugging is spent editing code based on a guess about what is wrong. Ten seconds in the Elements panel usually tells you what is actually happening, and then the fix is obvious.

The method is short and it works. Reproduce it reliably — a bug you cannot trigger on demand you cannot fix. Read the error, all of it; the first line usually names the cause and the rest is the trail. Form one hypothesis about the cause. Test that hypothesis with the smallest possible change. Then either it is fixed, or the hypothesis was wrong and you form the next one.

The failure mode is the opposite: changing several things at once and seeing whether it improves. When it does improve you do not know which change worked, so the bug remains partly there; when it does not, you have made the code worse and lost the state you were reasoning about. One change at a time is slower per attempt and dramatically faster overall.

Then the two techniques that find almost anything. `console.log` the values at each step, because a bug is nearly always a value that is not what you assumed — and logging beats staring at code, which shows you what you meant to write. And bisect: comment out half the code and see whether the bug persists, then halve the remaining half. A few rounds locate the cause in code you would otherwise search for an hour.

Error messages read like accusations and are actually instructions. 'Cannot read properties of null' means you tried to use something that was not there — a selector that matched nothing, or a value that had not loaded yet. 'is not a function' means you called something that is not callable, usually a typo in the name or a missing import. 'Unexpected token' is almost always a missing bracket, quote or comma a few lines above the reported line.

The discipline is to read the whole message and the line number, then look at that line before theorising. Most people read the first three words and start guessing. The line number is nearly always right, and the code there nearly always tells you what happened.

Then a distinction worth internalising: a syntax error stops the script entirely and nothing runs, while a runtime error stops execution at that point and everything before it already happened. If your whole page is dead, look for a syntax error; if one thing does not work, look for a runtime error at the moment that thing runs. Knowing which you have halves the search.

Responsive testing means actually looking at the page at real widths, not resizing once and assuming. Test at roughly 320px (a small phone, where things break first), 375px, 768px (a tablet), 1024px and 1440px. The device toolbar in developer tools does this, and it also simulates touch — which catches buttons too small to tap, a problem you cannot see with a mouse.

Then check the things that only appear at small sizes: text overflowing its container, images wider than the screen causing horizontal scroll, tap targets smaller than about 44 pixels, and navigation that does not fit. Horizontal scrolling on a phone is the clearest sign something is broken, and it is almost always one element wider than the viewport.

For performance, three things dominate and they are all fixable. Image size — by far the most common problem, because a 4MB photo from a phone makes a page take seconds to load on a mobile connection; resize and compress before uploading. Render-blocking resources — large stylesheets and scripts in the head that delay first paint; use `defer` on scripts. And too many requests — dozens of small files each cost a round trip. The Network panel shows all three, and Lighthouse names them for you.

Before publishing, run the accessibility checks from earlier in the course as a list rather than a hope: keyboard-only navigation reaching everything, visible focus everywhere, contrast at 4.5:1 or better, alt text on images, labels on inputs, one h1 with a logical outline, and no information conveyed by colour alone. Lighthouse audits most of this automatically and names what fails.

Then basic SEO, which is mostly about being describable rather than tricks. A `<title>` on every page that says what the page is — not 'Home' on all of them. A `meta description` summarising the page, which is what appears in search results. One h1 stating the subject, with headings nested logically so the outline describes the content. Alt text on images, which is also how images appear in image search. And a `lang` attribute on the html element so the language is known.

The honest summary is that good semantics is most of SEO. A page built with the right elements, real headings, descriptive links and alt text is already well optimised, because those are exactly the signals search engines read. There is no separate technique to learn — the accessible page and the searchable page are the same page.