Frontend Achievements on a Resume Without Fake Metrics

11 min read

You did real UI work. The resume still reads like a keyword cloud with mystery math at the end. That's not because you're bad at writing. It's because template bullets train you to paste metrics you never measured.

Hiring managers skim for proof they can probe on a tech screen: components you own, perf fixes you can open in DevTools, accessibility paths you tested. Fake or borrowed numbers collapse the minute someone asks which release carried the change.

Before you rewrite bullets, check your resume for free on the PDF you'd upload to Greenhouse. If Experience parses clean, the next job is replacing weak achievement lines with ones you'd defend to an engineering manager.

This page judges common frontend bullets, shows before and after pairs across roles, names what weak versions share, and gives you a copy-paste block for honest perf and accessibility lines.

You are not dumbing down your impact. You are making ownership visible to recruiters who have six minutes and a parsed Workday row, not your Jira board.

If imposter syndrome pushes you toward round percentages, write the bullet without a number first, read it aloud, then add a metric only when you can answer two follow-up questions about how you measured it.

What recruiters grade frontend achievements against

Strong lines tie how to write frontend achievements without fake metrics to shipped work: surface, constraint, change, outcome you can explain without a slide deck. Weak lines paste outcomes from someone else's dashboard.

The bar isn't a novel per bullet. It's a line that survives "what did you personally change in the repo?" If the honest answer is vague, the bullet is decoration.

For deeper perf framing on US files, see how to show web performance wins on a US resume . For accessibility proof patterns, pair with show accessibility impact on a frontend resume .

The standard is simple: could you open the repo, find your PR, and talk for five minutes without reading the resume? If yes, the bullet is ready. If no, trim the metric or narrow the surface until the answer is yes.

Junior engineers worry honest lines look thin. Two specific shipped tasks beat five inflated percentages when a senior engineer reads the stack. Depth on one route signals more than breadth on none.

Before and after pairs across frontend roles

Product UI engineer (React, checkout)

Before: Improved Core Web Vitals by 40% across the ecommerce site.
After: Refactored checkout step two to lazy-load payment SDK; cut LCP on /checkout from 4.2s to 2.9s in Chrome field data for that route after the Q2 release.

Design systems engineer

Before: Built a scalable component library used company-wide.
After: Shipped Button and Modal v2 in the shared React package; migrated six product squads off legacy CSS modules with codemods and Storybook docs they adopted in Q3.

Growth frontend (experiments)

Before: Ran A/B tests that increased conversion dramatically.
After: Implemented pricing page experiment shell in Next.js; partnered with data on two variants, shipped winner that raised trial starts on /pricing in internal experiment readouts you can reference.

Internal tools frontend

Before: Enhanced admin dashboards for better UX.
After: Rebuilt ops dashboard filters in TypeScript; reduced time-to-first-action for tier-two support by replacing three legacy API calls with one batched endpoint you documented for the backend team.

Mobile-web hybrid

Before: Optimized mobile performance metrics.
After: Fixed layout shift on marketing hero by reserving image slots in CSS; cleared CLS on /home in Lighthouse runs you captured before and after the August deploy.

Embedded widget / third-party script owner

Before: Managed third-party integrations for analytics and chat.
After: Wrapped chat SDK load behind consent banner you shipped; deferred script inject until after first paint on logged-in dashboard routes you maintained.

Frontend lead without people manager title

Before: Led frontend team to deliver multiple projects.
After: Set PR review standards for accessibility on checkout squad; unblocked three releases by pairing juniors on Storybook tests you added to CI gates.

I've passed on files where every bullet was a round percentage with no route, then watched the same candidate shine on a screen share because the work was real but the PDF lied about ownership.

Copy-paste block: honest frontend bullets

Replace bracket text with your release facts. Numbers below are illustrative resume examples, not hiring market claims.

• Shipped [feature] on [route/stack]; [specific change] after [release window]
• Cut JS payload for [module] from [X]kb to [Y]kb via [code-splitting/tree-shake] you merged
• Fixed a11y on [flow]: keyboard path through [screens]; paired with QA on [VoiceOver/NVDA]
• Migrated [N] screens from [legacy] to [design system components] with [tests/storybook] you owned
• Partnered with backend on [endpoint]; reduced [client calls/loading state bugs] on [surface]
              

Before: Skills row lists React, Vue, Angular, Svelte with no project dates.
After: Two Experience bullets name React plus TypeScript on the product you shipped last year; Skills holds only stacks you would whiteboard today.

Edge case: perf work was mostly config suggested by platform. Credit the change you merged: image CDN rules, font preload, or route-level split, not the whole site's score.

Edge case: startup with no formal metrics culture. Use scope and release facts: owned checkout UI through Series B launch, on-call for P1 UI defects two quarters, mentored one intern on component tests you added.

Staff-level candidates still need owned slices. Architecture bullets should name decisions you drove: chose module federation for micro-frontends on seller portal, documented tradeoffs in ADR reviewers approved.

Contract frontend engineers should tie bullets to client deliverables with Month Year ranges inside the agency block so parsers see which engagement owned which route.

Interviewers often open with the first bullet under your current role. If that line is a vague percent, the next thirty minutes become damage control. If it names a route and release, the conversation starts on code you remember.

When you lack field data, describe the measurement you used locally: Lighthouse on your branch, WebPageTest on staging, or RUM slice your team agreed to watch. That is still honest if you say where you captured it and what you changed before the number moved.

Platform teams move scores without your UI diff. Credit platform wins only when you merged the config or component hook that enabled them. Otherwise stick to UI scope: skeleton loaders you added, font subsetting you shipped, image dimensions you fixed.

Before: Collaborated with cross-functional teams to deliver features.
After: Paired with design on checkout error states; shipped inline validation in React that reduced support tickets tagged payment-errors in Zendesk views your PM tracked.

Before: Responsible for responsive design.
After: Rebuilt navigation breakpoints for tablet widths on marketing pages; eliminated horizontal scroll bugs QA filed under ticket MOB-4412 before launch.

Open-source contributions belong when you can name the PR and maintainer context. One merged perf fix in a library you use at work beats ten starred repos with no merge link.

What weak frontend achievement lines share

Percentages with no surface. If the bullet does not name a route, component, or release, assume it will fail a follow-up question.

Borrowed KPIs from marketing slides. Site-wide conversion lifts are team stories. Your bullet should describe the UI change you merged.

Before: Improved SEO and performance across properties.
After: Added structured data and image lazy-load on blog templates you maintain; documented Lighthouse before/after for /blog on your branch.

Framework name-dropping without shipped proof. Icons are not achievements. Dated bullets with a merge or release are.

Accessibility claims without a tested flow. Say which screens and which assistive path you verified, not that the whole app is compliant.

Listing build tools as achievements. Webpack or Vite config matters when you changed it and can describe bundle impact on a module you own, not when you copied defaults from a template.

Before: Monitored analytics dashboards daily.
After: Built event hooks for signup funnel steps you shipped; worked with analytics on naming so experiment readouts matched your components.

Before: Ensured high code quality across the team.
After: Added Playwright smoke tests for checkout paths you maintained; blocked two releases until flake fixes you wrote landed in CI.

Weak bullets often share passive voice and team verbs with no owner. Flip to what you merged, reviewed, or on-called for, still truthfully.

Tools before you upload frontend files

Run the free ATS resume checker on your export. Frontend resumes break when two-column portfolios scramble Experience order in Workday.

Paste the posting into job match score and rewrite bullet one to mirror paragraph one with honest scope, not invented metrics.

When a posting asks for a letter, use the cover letter generator after bullets are true so the letter repeats one shipped change, not recycled KPIs.

Tailor bullet one per req after you score match, but do not invent metrics per company. Swap surface names and stack keywords that appear in paragraph one while keeping the same honest releases you can discuss on a screen share.

Save PDF exports with filenames that include the req ID. When a recruiter replies six weeks later, you will know which bullet version they read and which route story to reopen without guessing.

Two tools in one apply block is enough: checker for parse order, match score for wording gaps. Adding more tabs usually delays submit without improving honesty.

Ship honest frontend lines tonight

Frontend achievements without fake metrics come from owned surfaces, releases, and tests you can demo. Swap borrowed KPIs for routes and merges you defended in code review.

• Pick three shipped changes and rewrite bullets with route plus release context.
• Delete percentages you cannot tie to your merge.
• Move stack proof from Skills into Experience with dates.
• Run a parse check before you mass apply to React reqs.

Open your master file, paste the copy-paste block, and run a free ATS check on the export. When bullet one names a real route, phone screens start on work you actually did.

You do not need inflated math to compete. You need lines that match the repo stories you tell when someone shares their screen and asks you to walk through the diff.

Keep a short changelog each sprint: route, PR link, metric or scope note. Resume updates become copy-paste instead of guesswork the night before you apply.

If a bullet makes you nervous in a mock interview, delete the number and keep the surface. Nervousness is often a signal the metric was never yours.

Staff and principal titles still follow the same rule: name the decision or module you owned. Architecture without a merge is a blog post, not a resume line.

Returning from a gap, lead with the most recent shipped work you can demo, even if it was a contract engagement. Honest dates plus route proof beat a silent gap filled with inflated percentages.

Your manager can confirm scope in a reference even when they cannot share revenue. Write bullets they would nod along to on a call, and you will stop fearing the verification step.

Block one hour this week to rewrite three bullets using the copy-paste frame. Run the checker once. That single session usually clears more fake metrics than another pass on font choice or resume color.