What I built
Katas Raj Heritage 3D is a site I built for my Platform & Web Engineering internship with PreserveMy.World — it combines a MobileNetV2 image classifier, an HTML5 Canvas AR measurement overlay, and a Three.js 3D mesh viewer for the Katas Raj temple complex in Chakwal, Punjab.
- Live site: katas-raj-heritage-3d.vercel.app
- Repo: github.com/Anfey-SE/katas-raj-heritage-3d
Why I went back to it
This is Week 6 of my internship's make-up work track, and the task was to take a prior artifact and prove I'd actually improved it — not just say I did. I picked this project because I had a real audit trail: a Lighthouse-driven fix I made and verified in Module 21, plus a follow-up check I ran while preparing this write-up.
What the first audit showed
Back in Module 21, I ran a Lighthouse audit (Mobile, Navigation mode) on the deployed site and found real, specific issues:
- SEO: 83
- Accessibility: 92
Specifically: a missing meta description, an invalid/missing robots.txt, a missing <main> landmark, a non-sequential heading order (h1 jumping to h3), and a favicon 404 in the console. I didn't screenshot that run before fixing things — a mistake I'm not repeating this time — but the flagged issues and scores are saved in a text output from that session.
Performance wasn't part of this claim. That run flagged Performance as unreliable due to browser extensions and throttling, so I didn't treat it as fixable data — more on that below.
What I actually fixed
Real commits, in order:
e5b6fbf— add robots.txt
The site had no robots.txt at all. Added one so crawlers have explicit instructions instead of guessing.52fb5ac— add meta description, favicon, main landmark, heading hierarchy
The page was missing a meta description (so it had no real search-result snippet), had no favicon, no<main>landmark for screen readers to jump to, and its heading tags weren't in a logical order. Fixed all four.
After making these fixes, I verified the Vercel deployment shipped correctly, then re-ran Lighthouse and confirmed:
- SEO: 83 → 100
- Accessibility: 92 → 100
That's the core result — two real, measured scores moving because of specific, identifiable fixes, not a rerun trick.
A performance note
While preparing this write-up, I ran Lighthouse again to double check the site's current state, and noticed the Performance score came back invalid — Chrome extensions were interfering with the page load. I re-ran it in a clean incognito window and got a real Performance score of 62. That's not something I'm claiming as "fixed" here since it wasn't part of the original scoped work, but I did make one real change along the way: I noticed the Exhibit C iframe was loading eagerly on first paint and switched it to lazy-load, since it's one likely contributor to a slower initial load. That's a smaller, secondary improvement worth mentioning honestly rather than folding into the headline numbers above.
Lighthouse flagged this run as invalid due to Chrome extensions
Clean incognito re-run — real Performance score
A separate fix: smoothing the 3D relief
Alongside the audit work, I also went back into capture_to_3d_depth.html — the capture-to-3D viewer — and fixed something that had nothing to do with Lighthouse scores: the relief mesh looked noisy and jittery instead of smooth.
The cause was that depth displacement was being computed directly from raw per-pixel luminance values, which produces a static-like bump surface. The fix was to box-blur the luminance data before using it as depth, while leaving the actual photo texture untouched and sharp — so the surface reads as smooth geometry with a crisp photo on top, instead of a jittery mesh.
While I was in there, I also added a soft radial contact shadow under the mesh so it reads as resting in the scene rather than floating above it, and eased the camera's starting distance so it dollies in gently on load instead of snapping straight to position.
None of this shows up in a Lighthouse score. It's a rendering-quality fix, verifiable by opening the page and comparing the mesh surface and camera behavior before and after — commit d40e511.
The hard part
The heading hierarchy fix looked trivial but wasn't — changing h3 to h2 meant tracking down the matching CSS selector too, since the site's styling was keyed to the tag name, not a class. Missing that would have fixed the semantic structure but broken the visual layout. That's the kind of thing an automated score won't warn you about either way.
What I'd improve next
- Get a valid Lighthouse baseline before making any changes next time, run in incognito from the start, so before/after numbers are directly comparable.
- The AR canvas and Three.js viewer are still the heaviest parts of the page — next step would be code-splitting them so they load on demand instead of on initial page load.
Connection to PreserveMy.World
A heritage site is only as useful as the number of people who can actually load and read it. Slow performance and weak semantic structure quietly gatekeep who gets access — someone on a low-end phone, or someone using a screen reader, is exactly the kind of public audience PMW's mission is built around: students, researchers, and diaspora communities engaging with Pakistani heritage sites they may never visit in person. A technically solid, accessible page isn't a side detail to the preservation work — it's part of what makes the preservation actually reach people.
What I verified manually
I ran the Lighthouse audit myself, read through the flagged issues to confirm which were real and fixable, edited index.html directly, verified the Vercel deployment succeeded (Ready status, correct commit hash), and re-ran Lighthouse afterward to confirm the score changes. For the performance check, I re-ran in a clean incognito profile and cross-checked the fix against the live deployed site.
Evidence:
Top comments (0)