Web development
Web development best practices: ten that pay off
Ten web development best practices with a measurable return: small commits, behaviour tests, lint in CI, performance budgets and reuse.
Key points
- A practice is useful only if it produces an automated check: without CI it becomes advice nobody follows.
- Behaviour tests survive refactors; implementation tests need rewriting at every structural change.
- Reusing components and blocks reduces new code, which is the first source of defects.
- Regulation (EU) 2016/679, article 25, requires privacy and security in the design, not after the first incident.
The web development best practices that pay off are the ones an automated check can enforce: small commits, behaviour tests, lint in CI, performance budgets and component reuse. The rest stay good intentions until a command fails.
The ten practices, in order of return
How to enforce them without meetings
The difference between a practice and an opinion is the command that checks it. Put lint and Lighthouse CI in the pipeline: the first blocks style drift, the second blocks performance regressions. If the check is slow, run it only on changed files, but do not remove it.
npx eslint . --max-warnings=0
npx @lhci/cli autorun --collect.url=https://example.comDo not invent the thresholds: LCP under 2.5 seconds, CLS under 0.1 and INP under 200 ms are the values Google uses to classify a page. How to set them in a workflow is in Lighthouse CI thresholds.
Security and privacy: two references to know
Regulation (EU) 2016/679 of 27 April 2016, article 25, requires data protection by design and by default: collect only the fields you need and delete them when they are no longer needed. Article 32 requires measures proportionate to the risk, including encryption and access control. This is not only a legal matter: a form that sends personal data in the clear is a technical defect, not a product choice. For accessibility the reference remains WCAG 2.2, and for Italian public administration legge 9 gennaio 2004, n. 4, article 3.
The practice nobody mentions: write less code
Every line written has to be read, tested and maintained. Reusing a proven block costs configuration; rewriting it costs a feature and a future defect. The form components cover validation and error states, the tables cover sorting and pagination, and a settled library such as shadcn/ui brings accessible behaviour without inventing it. The comparison of Tailwind and Bootstrap helps pick the right level of abstraction.
Where these practices stop
On a legacy project without tests, introducing a full pipeline in one day blocks the release. In a one-person team there is no peer review, so it has to be replaced by stricter automated checks. And no practice replaces domain knowledge: a green test on a function that solves the wrong problem is still a useless green test.
Where to start this week
Frequently asked questions
Which web development practice matters most?
Code review on small changes: it catches defects no tool sees and spreads knowledge through the team. Pair it with lint and automated tests, otherwise it depends on who is available.
How many tests does a website need?
There is no right number. You need tests for the paths that create value, such as login, payment and form submission, plus a smoke test that says in thirty seconds whether the site is broken.
Is TypeScript mandatory?
No, but it reduces errors in projects that grow and last. On a script of a few lines the setup cost can outweigh the benefit.
What is the difference between lint and tests?
Lint analyses code without running it and finds risky or inconsistent patterns. Tests run behaviour and check the result. You need both because they see different problems.
Is performance a development practice or a final task?
It is continuous. Setting a budget and measuring it on every change costs little; optimising everything at the end costs a lot and often means rewriting components.