Custom properties are the first thing I set up on every project. I put colours, spacing and type sizes on :root, and each component reads from them.
:root {
--color-ink: #1d1b18;
--color-paper: #f7f4ef;
--space-md: 1rem;
}
.card {
color: var(--color-ink);
background: var(--color-paper);
padding: var(--space-md);
}
If the client changes the brand colour, I edit one line. Dark mode is a second block inside a media query, not a second stylesheet. Unlike Sass variables, custom properties exist at runtime, so a small script can change them too, for example when a visitor flips a theme switch.
Most big stylesheets do not go wrong because of the syntax. They go wrong because two rules fight over specificity, and somebody reaches for !important. Cascade layers fix that. I declare the order once at the top of the file, then put each part of the site into its own layer.
@layer reset, base, components, utilities;
Anything in a later layer wins, however specific the selector is. My utilities layer sits last, so a one-off margin always works. I have not needed !important in a client project for a long time.
Media queries ask about the window. A card in a narrow sidebar and the same card in a wide grid need different layouts, but the window width tells you nothing about either. Container queries ask about the space the component really has. I set container-type: inline-size on the wrapper, then write rules for the card inside it. The card now looks right wherever I drop it.
I am not against frameworks. A team of six working on a large app, or a design system shared across several products, can gain a lot from a component model and a build pipeline. A five-page site for a dentist does not need either.
My rule is simple. If I can describe the whole design in a page of custom properties and a few layers, I skip the tooling. Every dependency is something to update, debug and pay for later. A plain stylesheet has no build step to break and no generated file to read when something looks wrong. The browser does the work, and the page loads faster for it.
Most CSS bugs I have seen came from a rule I forgot I wrote, not from the language itself. Keep the file small, and it stays easy to read.
I still reach for a framework now and then. Most of the time, though, plain CSS is the quickest route to a site that looks right and stays easy to change.
]]>A browser cannot paint the page until it has the CSS for it. If that CSS sits in a file the browser has to fetch first, the screen stays blank for longer. I inline the small amount of CSS needed for the top of the page, the critical CSS, straight into the head. The rest of the styles load as a normal stylesheet after that.
<head>
<style>
body { margin: 0; font-family: "Inter", sans-serif; }
.hero { min-height: 70vh; display: grid; place-items: center; }
</style>
<link rel="stylesheet" href="/css/site.css" media="print" onload="this.media='all'">
</head>
The inline block only covers what the visitor sees first. Everything else can wait a few milliseconds.
Web fonts are a common cause of slow text. Each family and weight is another request, and the text can stay invisible while the file loads. I use one family, usually a variable font, in two weights at most. I preload the file that holds the body text, and I set font-display: swap so visitors can read something straight away.
I also check the fallback font. If its sizes are close to the web font’s, the text barely moves when the real font arrives. That keeps the layout stable, which matters for the score as much as the speed does.
Most of the page weight on a portfolio or a shop is images. I export everything as WebP at a few widths, then let the browser pick the one that fits the screen. A phone should never download the desktop hero. I give every image a width and height, so the browser can reserve the space before the file arrives. Lazy loading goes on anything below the fold, and never on the hero image, because that one is needed straight away.
Chat widgets, video embeds, social feeds and tag managers are where most scores go to die. They load a lot of code, often before the visitor has done anything at all. My default is a plain placeholder. For a chat widget, that means a button that says “Chat with us”. The real script loads when the visitor clicks, so the first paint is not held up by code they may never use.
Analytics is the one thing I keep running from the start. I use a small, privacy-friendly script, load it after the page has finished, and check its cost in the trace.
I run PageSpeed on the mobile test, because it is the harder one. My laptop is quick, so local scores can look fine while the real visitor on a cheap phone waits. Where the client already has traffic, I also check the field data. I change one thing at a time, so I know which change actually helped.
A hundred is a nice number, but the real goal is a page that opens fast for the person who needs it. The score is just the proof that the basics are in place.
]]>A design file is a promise. It shows a button at one size, in one frame, with a heading that always fits on one line. The browser does not work like that. Text wraps, images change shape, and the menu breaks at 380 pixels. Finding those problems after the design is approved costs time and trust.
When I design in the browser, those problems show up on day one. I can see how a heading wraps at tablet width and fix it before the client sees anything. The design is the thing that gets built, so there is no handover where details get lost on the way.
The gains are real. I work with real content, not lorem ipsum. I test spacing with the actual fonts and colours, in light and dark mode. Change a colour token and every page updates at once. The client can open a preview link on their phone and comment on the real thing, not on a picture of it.
I do lose some things. Exploring is slower in code than on a canvas. Nobody wants to write twelve versions of a hero section just to see which one feels right. I also need to be comfortable with a bit of mess, because a browser draft looks rough until the last hour.
A design file shows you one picture. A browser shows you every size a visitor might use.
I still sketch first in three cases. The first is a brand-new concept, when the client does not yet know what they want. A few rough boards on paper keep the conversation about ideas rather than pixels. The second is a complex flow with many steps, such as a booking process. Drawing the path helps me see where people might get stuck before I write any markup. The third is a project where the client needs to approve a direction before any code exists.
Even then, the sketching is short. I spend an hour or two on paper, then move into the browser. I keep the sketches for reference, but the browser decides the final look.
My first session on a new project is always the same. I write the colour tokens, the type scale and one page filled with real content. Then I resize the window until something breaks, and fix it. By the end of the first day I have a rough site I can show. It is not pretty yet, but it is honest about how the design will behave on the screens people actually use.
]]>Write the scope down before you quote. A short list of pages, features and content owners saves more arguments than any contract clause. If a feature is not on the list, it is extra, and it gets its own price.
Ask who writes the words. Most delays I have seen were not in the code. They were waiting for copy. I ask for the text, or for a named person who will write it, before I agree on a launch date.
Charge for the extra rounds of feedback. One round of changes is part of the job, and two is fine on a small project. After that, every round eats into the margin. I say so early and put it in writing.
Build the boring parts first. Forms, contact details and the mobile menu are the things clients test first. I make sure they work with real data in week one, not the night before launch.
Keep a note of every decision. Clients forget what they agreed to, and sometimes so do I. A short email after each call, with the date, saves a lot of trouble at the end.
Hand over with a short guide. Two pages on how to edit the content, where the files live and who to call about hosting. Clients who can edit their own site send fewer emails.
Say no to the wrong clients early. Some enquiries are not a fit. The budget is unclear, nobody can make decisions, or the deadline cannot work. A polite no in the first week is kinder to both sides than a stressful project that nobody enjoys.
These lessons did not come from reading books. They came from small failures that were obvious in hindsight. Once I started writing scope notes and asking about copy up front, my projects ran to time more often. My late nights dropped, and so did the tension with clients.
Early on I thought my job was to make the site look good. Most of the work is really about making decisions visible. When everyone agrees on what is being built, who is doing what and when it will be finished, the design almost takes care of itself. I wish somebody had told me that earlier. It would have saved me a lot of evenings spent fixing problems I could have seen coming.
]]>