The web dev knowledge that isn't code

Understanding what happens between typing a URL and seeing a page is the skill that separates web developers from framework users. It makes every bug — slow loads, CORS errors, stale caches — explainable instead of mysterious.

Every page load is the same journey: the browser resolves the domain to an IP address (DNS), opens a connection (TCP), secures it (TLS), sends an HTTP request, receives a response, then parses HTML into the DOM, computes styles, and paints pixels. Each stage can fail, be slow, or be cached — and each produces different symptoms. Step through the journey:

HTTP status codes — quick reference

Make it a habit

Most attacks on websites aren't clever — they exploit the same handful of oversights, year after year. Knowing the top few puts you ahead of the majority of shipped sites.

The classics: XSS (user-supplied text rendered as live HTML — the reason you escape output; try the HTML entity tool), CSRF (another site triggering actions with your users' cookies — mitigated by SameSite cookies and tokens), supply-chain risk (that convenient npm package and its 300 dependencies run with full access to your page), and secrets in client code — anything shipped to the browser is public, including API keys in your JavaScript. Security headers are the highest-value low-effort defence; this very site ships the set below.

Tighten or loosen CSP per site — start strict, then allow only what breaks. Test with your browser DevTools console open; violations are logged there.

Make it a habit

Speed is a feature users feel and Google measures. Three numbers — the Core Web Vitals — summarise it, and they're ranking factors.

The biggest wins are boring: compress and size images properly (reserve space with the aspect ratio tool to protect CLS), let the browser cache aggressively, load JavaScript only where it earns its weight, and keep third-party scripts on a short leash. Caching is where most sites leave speed on the table — these three recipes cover the common cases:

no-cache does not mean “don't cache” — it means “store it, but check with the server before reusing it”. The one that disables caching entirely is no-store.

Make it a habit

Roughly one in six people has a disability that affects how they use the web. Accessibility isn't an add-on for them — it's baseline quality, and increasingly a legal requirement (WCAG 2.2 AA in the UK and EU).

The 80/20 of accessibility is semantic HTML: real <button>s, real <a>s, headings in order, landmarks (<nav>, <main>, <footer>). Native elements bring keyboard support, focus behaviour and screen-reader announcements for free — a <div onclick> brings none of them. Reach for ARIA attributes last, only when no native element fits. And check your colours with the contrast checker.

Make it a habit

Git is the safety net that makes fearless experimentation possible — and the collaboration layer every team assumes you know. You need about twenty commands, used well, not two hundred.

The mental model that makes Git click: commits are snapshots of your whole project, branches are just movable labels pointing at a snapshot, and almost nothing is ever truly lost. Small, focused commits with messages that explain why turn your history into documentation.

Make it a habit

A site on localhost helps nobody. Getting comfortable with domains, DNS and hosting turns “it works on my machine” into a URL you can put on a business card.

The modern path for static sites is genuinely easy: push to Git, connect a host (Cloudflare Pages, Netlify, GitHub Pages, Vercel), and every push deploys automatically with HTTPS included. The part that still confuses everyone is DNS — the records that point your domain at your host:

DNS changes take time to spread (propagation, up to 24–48h but usually minutes). Lower the record's TTL before a planned switch, and don't panic-edit while it propagates. Before launch, generate your robots.txt and submit your sitemap.

Launch-day checklist

Tests aren't bureaucracy — they're the difference between “I think it still works” and “I know it still works”, every time you change anything.

Start where the value is: pure logic first (date maths, price calculations, validators — cheap to test, painful to break), then your critical user paths (sign-up, checkout, the thing your site exists for). A handful of tests on what matters beats hundreds of tests on what doesn't. Test behaviour users can see, not implementation details — tests that break on every refactor teach teams to ignore them.

Make it a habit

Privacy law (GDPR in Europe, similar laws spreading worldwide) turned “collect everything, sort it out later” into a liability. The principle that keeps you safe is simple: collect the minimum, and be honest about it.

You've already seen this page practise it: the cookie banner here defaults analytics to denied until you accept, and every tool on this site runs client-side precisely so your input never needs collecting. “We don't store it” is the easiest privacy policy to honour. When you do collect data, know why, say so plainly, and delete it when the reason expires.

Make it a habit