Web development glossary: 40 terms in one sentence each
The forty web development terms a business owner meets in proposals, previews and progress updates, each explained in one plain sentence.
The short answer
Proposals, previews and progress updates about a website use a vocabulary that is rarely explained, and a business owner who knows forty terms can follow almost any conversation about their site and ask the right questions. The terms below fall into five groups: how a site is built, how it is styled and structured, how it performs, how it is measured, and how it is shipped. Each is explained in one plain sentence. When a term is used to justify a choice or a price, ask what it changes for your site and what the alternative would have been; the answer is usually shorter than the word suggested.
How a site is built
| Term | In one sentence |
|---|---|
| HTML | The markup that defines a page’s content and structure: headings, paragraphs, links, images, forms. |
| CSS | The styling language that defines how HTML looks: colours, type, spacing, layout, on every screen size. |
| JavaScript | The programming language that runs in the browser to add behaviour, and the main reason pages feel slow when overused. |
| TypeScript | JavaScript with types, which catches a class of mistakes before the code runs and is why we write in it. |
| Framework | A set of tools and conventions for building a site or application, such as Astro for websites and Next.js for applications. |
| Static site | A website delivered as ready-made files, built in advance, with no server computing pages per visit. |
| Server rendering | Building a page on a server at the moment it is requested, needed for personalised or constantly changing content. |
| Islands | Small interactive components loaded into an otherwise static page, so JavaScript runs only where it is needed. |
| Component | A reusable piece of interface, such as a button or a card, built once with its behaviour and styling and used everywhere. |
| Component library | The collection of a site’s components, styled from its tokens and documented, from which pages are assembled. |
| Design system | The tokens, components, patterns and principles that make a site consistent and refreshable in place. |
| Design tokens | Named values for colours, type and spacing that every component uses, so a change in one place changes the whole site. |
| Headless CMS | A content system that stores and edits content and hands it to the site through an API, without rendering pages itself. |
| Content model | The definition of what a piece of content consists of, such as an article’s title, summary, body, image and topics. |
| Markdown | A plain-text way of writing formatted content that is easy to edit, version and build into pages. |
How a site is structured and styled
| Term | In one sentence |
|---|---|
| Semantic HTML | Using the elements that describe meaning, such as headings, lists and navigation, so browsers, search engines and assistive technology understand the page. |
| Responsive design | Layout that adapts to the screen size, from phone to large monitor, from one set of code. |
| Mobile first | Designing and building for the phone first and expanding for larger screens, rather than shrinking a desktop design. |
| Progressive enhancement | Building the essentials to work with HTML and CSS and adding JavaScript as improvement, so the site works when scripts fail. |
| Accessibility | Building so that people with disabilities can use the site, measured against the WCAG standard and required by law for many organisations. |
| WCAG | The Web Content Accessibility Guidelines, the international standard, with level AA as the usual legal and contractual target. |
| Structured data | Machine-readable annotations describing a page’s content, such as a business, an article or a product, used by search engines and assistants. |
| Canonical URL | The address declared as the main one for a page’s content, so duplicates do not compete with each other in search. |
How a site performs
| Term | In one sentence |
|---|---|
| Core Web Vitals | Three measurements of loading, responsiveness and visual stability that search engines use to judge page experience. |
| Largest Contentful Paint | How long until the main content of a page is visible, the loading measurement. |
| Interaction to Next Paint | How quickly the page responds when a visitor taps or clicks, the responsiveness measurement. |
| Cumulative Layout Shift | How much the layout moves unexpectedly while loading, the visual stability measurement. |
| Lab data | Measurements from a tool loading a page under simulated conditions, useful for diagnosis. |
| Field data | Measurements from real visitors’ browsers, which is what search engines use and what visitors experienced. |
| Performance budget | Limits on page weight and metrics, enforced in the pipeline so a site cannot slowly get heavier. |
| Lazy loading | Loading images and components only when they are about to be seen, so the first view is light. |
| Third-party script | Code from another company running on your page, such as analytics or a chat widget, each a cost in speed and privacy. |
How a site is shipped
| Term | In one sentence |
|---|---|
| Repository | The versioned store of the site’s code, content and setup, which the business must own. |
| Version control | The system that records every change, who made it and why, and lets any change be undone. |
| Build | The step that turns source code and content into the files visitors receive. |
| Pipeline | The automated sequence of checks, build and deployment that every change passes through. |
| Preview | A copy of the site built from a proposed change, at its own address, so it can be reviewed before it goes live. |
| Deployment | Putting a built version of the site live, atomically, with the previous version kept for rollback. |
| Rollback | Restoring the previous version in one step when a change turns out wrong. |
| Technical debt | The accumulated cost of shortcuts, which shows up as a slower site and slower changes until it is paid down. |
Using the glossary
- Read a proposal with the glossary open and translate each technical claim into what it does for your site.
- Ask about any term that cannot be placed in one of the five groups or explained in a sentence.
- Check the shipping terms first: repository, version control, pipeline, preview, in whose name.
- Check the performance and accessibility terms for how the result will be judged.
- Then compare prices, because two proposals using the same words rarely describe the same work.
What this means for you
Forty terms cover almost every conversation about building, styling, measuring and shipping a website. Knowing them lets you read a proposal for what it buys, a progress update for what happened, and a hand-over for what you own. Ask about anything that does not fit, and treat words that cannot be explained plainly as a reason to ask more, not as a reason to pay more.
Frequently asked questions
Which of these terms matter most for a business owner?
Repository, version control, pipeline and preview, because they explain how changes reach your site safely and what you own; static site, framework and component, because they explain how the site is built; Core Web Vitals and field data, because they explain how it is judged; and accessibility, because it is both a legal matter and a quality one. The rest are useful when they come up.
A proposal used a term that is not here. What should we do?
Ask for it in one sentence and ask what it changes for your site. A good partner explains readily and connects it to a decision you can understand. If the term cannot be explained plainly, it is either unimportant or doing persuasive work that the explanation should be doing instead.
Why does the same word mean different things to different suppliers?
Because some terms are marketing as much as engineering. Custom, modern, optimised and responsive are stretched to fit what is being sold. The definitions here describe what the thing is or does. Where a supplier's usage differs, ask for the specific capability they mean and whether your site needs it.