Engineering note
How this portfolio keeps performance honest.
A portfolio should feel polished, but it should also load quickly and stay readable on the devices a recruiter or engineering manager is actually using. This site keeps that discipline visible in the code.
The budget
The repository has a static quality check that protects the basics: total JavaScript, total CSS, image weight, resume PDF weight, image dimensions, async image decoding, and direct-contact link access. The separate Lighthouse budget is an aspirational production-quality gate for deployed reports, not a claim that the site currently has passing Lighthouse evidence.
The lightweight JavaScript rule
The homepage uses local scripts only. JavaScript is scoped to project card rendering, frame-batched scroll progress, reveal states, navigation behavior, and active section highlighting.
The font rule
Typography is served from local WOFF2 files instead of Google Fonts runtime requests. The site keeps the same Inter and Playfair Display identity while reducing third-party dependency during page load.
The image rule
Above-the-fold hero images are explicit about priority. Supporting project images use responsive WebP sources, fixed dimensions, async decoding, and lazy loading unless they are the case-study hero image.
The current tradeoff
The portfolio is intentionally static, but it still has a small amount of JavaScript for project-card rendering, scroll progress, reveal states, active navigation, and direct contact links. That keeps the interaction layer useful without turning the portfolio into an application shell.
The next improvement
The next useful step is deployed Lighthouse evidence for the homepage and case-study pages, plus a small visual regression pass on mobile. That would make the quality bar measurable outside a local machine.
Evidence workflow
Local checks protect the structure before deploy: JavaScript syntax, static budgets, image attributes, local scripts, direct-contact access, and internal link integrity. Deploy-preview checks should then verify the homepage, work index, each case study, notes, sitemap, and robots file.
Lighthouse scores should be captured only from a real deploy URL and
recorded with the date, URL, viewport mode, and any known limitations.
If a score is not captured yet, the site should say that plainly rather
than presenting a target as a result. The production thresholds in
lighthouse-budget.json define the quality bar to verify
against; they are not published results on their own.