Nearly every front-end CV lists React and TypeScript, which means neither one differentiates you. What separates the CVs that get calls is evidence of what happened after the component rendered: how fast the page was, whether it worked for everyone, and whether you understand the platform under the framework.
What hiring managers are actually screening for
Front-end hiring has consolidated around three signals.
Performance ownership. Core Web Vitals are now a shared vocabulary, and a candidate who can say "cut LCP from 4.1s to 1.6s" has demonstrated diagnosis, measurement and follow-through in a single line. A candidate who says "optimised performance" has demonstrated nothing.
Accessibility competence. This has moved from bonus to baseline at any company with legal exposure, and it is increasingly a scored interview round. Concrete remediation work — violations closed, standards met, automated checks added — is unusual enough on a CV to stand out.
Platform depth. Interviewers routinely ask candidates to predict output order across promises and timeouts, implement debounce from scratch, or explain how the browser paints. CVs that read as framework-only invite scepticism about whether that depth exists.
The metrics that belong on a front-end CV
These are the numbers that make front-end work rankable:
- LCP, INP and CLS, stated before and after
- Bundle size in KB
- Time to interactive, ideally on a named device class
- Lighthouse scores
- Accessibility violations closed, against a named standard
- Conversion or task-completion rate on the surfaces you built
- Components shipped and reused across teams
Naming the device matters more than people expect. "Cut time-to-interactive to 2.1s on mid-tier Android" is far stronger than the same number without context, because it shows you tested under the constraint your users actually have rather than on your own laptop.
Before and after: front-end bullets
Weak: "Built responsive user interfaces using React, Redux, and CSS."
Strong: "Rebuilt the product listing page in React with virtualised rendering, holding 60fps scroll on 500+ items and cutting time-to-interactive from 6.2s to 2.1s on mid-tier Android."
Why: the framework names told the reviewer nothing, because everyone lists them. Naming the technique, the constraint and the measured result proves the depth the tools alone only imply.
Weak: "Made the website accessible and compliant with standards."
Strong: "Closed 340 axe-reported WCAG 2.2 AA violations across 60 screens and added automated accessibility checks to CI, preventing regressions on every subsequent PR."
Why: "made accessible" is unverifiable and reads as box-ticking. The CI gate is the important half — it shows you fixed the process rather than doing a one-off cleanup, which is what senior front-end hiring looks for.
Weak: "Worked closely with designers to implement mockups."
Strong: "Built and documented a 40-component design system in Storybook adopted by 5 product teams, cutting new-feature UI build time roughly 30%."
Why: implementing mockups is the baseline expectation. Reframing the same collaboration as leverage other teams consumed moves the bullet from execution to impact.
A summary that positions you
Three or four sentences naming your specialisation, your level and your strongest result:
Front-end developer with 5 years in React and TypeScript, focused on performance and accessibility in high-traffic e-commerce. Cut largest-contentful-paint from 4.1s to 1.6s across the checkout funnel, lifting mobile conversion 8%. Led the WCAG 2.2 AA remediation of a 60-screen product surface.
Note what this does: it establishes a niche (performance and accessibility, e-commerce), a level, and two results — all before the reviewer reaches your first job.
Skills worth listing
Core: semantic HTML, modern CSS (grid, flexbox, container queries), JavaScript fundamentals, TypeScript, React, state management, web accessibility (WCAG), Core Web Vitals, cross-browser debugging.
Tools: React, Next.js, TypeScript, Tailwind CSS, Vite, Webpack, Jest, Playwright, Storybook, Figma, Lighthouse, axe DevTools.
Keep this block tight. A list of thirty technologies reads as unfamiliarity with all of them; a focused list of twelve with bullets that substantiate them reads as depth.
What gets front-end CVs screened out
- No link to anything deployed. Conspicuous in this discipline specifically, because reviewers actually click. Two or three deployed projects with visible source beat a portfolio site.
- Framework lists with no platform fundamentals underneath. Invites the interview questions you least want.
- No performance or accessibility numbers anywhere. Reads as pixel-pushing rather than engineering.
- "Pixel-perfect" as a selling point. Signals a handoff mindset rather than a product one.
- A slow or inaccessible portfolio site. It is a work sample, and it will be judged as one.
How this scales by level
- Junior (0–2 yrs): deployed work and comfort with a framework plus real CSS.
- Mid (2–5 yrs): at least one measured Core Web Vitals or bundle improvement you owned.
- Senior (5–8 yrs): a design system, migration, or accessibility programme adopted beyond your own team.
- Lead (8+ yrs): framework or tooling decisions and their organisational effect.
Next steps
See the full breakdown of front-end developer CV examples, or prepare for the loop with front-end interview questions and what each round is scored on. You can also check your CV's ATS score free to see which sections are costing you points.