How This Portfolio Is Built: SEO, A11y & Speed

This site is 200 static HTML pages with one stylesheet, one JavaScript file, no framework, and no tracking. It deploys from GitHub Pages through Cloudflare, scores 99-100 on Lighthouse mobile performance at the homepage, and passes axe accessibility checks on every key page. This page documents how, with measured numbers instead of adjectives.

Stack and architecture

Hand-written HTML, CSS, and JavaScript. Georgia for prose, Departure Mono (self-hosted) for code and navigation accents. No frameworks, no build-time bundler, no third-party trackers, no cookies, no cookie banner. The single external runtime dependency is the Mermaid diagram library, which loads on demand only on pages that contain a diagram, pinned to an exact version with an SRI hash.

flowchart LR SRC[Source: HTML, CSS, JS, site-data.json] TOOLS[Build scripts: prerender, sitemap, feeds, search index, API, md mirrors] CI[GitHub Actions: deploy on push to main] PAGES[GitHub Pages: Jekyll pipeline, static output] CF[Cloudflare: CDN, TLS, headers] IN[IndexNow: changed URLs to Bing ecosystem] SRC --> TOOLS --> CI --> PAGES --> CF CI --> IN

The pipeline: derived files (sitemap, feeds, search index, JSON endpoints, markdown mirrors) are generated by small Python scripts in .tools/, committed with the source, and deployed as static files.

Build pipeline

Six idempotent Python scripts generate everything derivative. Content changes go in site-data.json or the pages themselves; the scripts do the rest.

Script	Generates
`build_prerender.py`	Static fallback content in the homepage (works with JavaScript off)
`build_sitemap.py`	sitemap.xml with per-page git lastmod and image entries
`build_feeds.py`	RSS, Atom, and JSON Feed for projects and labs
`build_search_index.py`	search-index.json for the client-side search (177 items)
`build_md_mirrors.py`	Markdown mirrors of key pages and llms-full.txt
`build_api.py`	/api/profile.json, projects.json, labs.json, skills.json

Measured results

Lighthouse mobile, simulated throttling, local server. The "before" column is the Phase 0 baseline preserved in docs/baseline/; "after" is the current build.

Page (mobile)	Performance before	Performance after	Accessibility after	SEO after
Home	56	99	100	100
Labs index	58	measured in CI	100	100
Lab page (Azure SQL)	56	92	100	100
Defence project (Sky radar)	57	measured in CI	100	100

The single biggest fix: the Mermaid library (about 680 KiB of JavaScript) was loading on every page, including the 17 with no diagram. It now loads only when a diagram exists. After that: AVIF and WebP versions of every image (one 2.2 MB JPEG became a 176 KB WebP), font and banner preloads, deferred scripts, and scrollable table containers instead of page-level overflow.

Accessibility

axe-core reports zero violations on all ten key pages, mobile and desktop. Contrast was raised to WCAG 2.2 AA on links and difficulty badges, tap targets meet 44px, the mobile menu closes on Escape and returns focus, every page has a skip link, and resume and lab pages print cleanly. The responsive matrix covers 20 viewports from 320px phones to 4K, plus foldables, with zero horizontal overflow.

Discovery strategy (SEO, GEO, AEO)

Every page carries a unique 50-60 character title, a 140-158 character description, canonical URL, Open Graph and Twitter cards, and JSON-LD that only describes what is visible: TechArticle and LearningResource on all 116 labs, BreadcrumbList everywhere, FAQPage only where a visible FAQ exists. Answer-first summary paragraphs open every lab, and each lab and project ends with a "Cite This Page" block (plain text, BibTeX, APA). For machine readers: llms.txt, llms-full.txt, markdown mirrors of key pages, JSON endpoints under /api/, and explicit robots.txt rules for search and AI retrieval crawlers with a one-edit switch to opt out of training crawlers.

Nothing here guarantees a ranking. The point is to remove every technical reason not to rank, and to make every claim on the site traceable to a visible page.

What I would change

Critical CSS inlining for the lab pages, which sit at 92-93 on mobile performance because the full stylesheet blocks first paint.
Self-hosting the Mermaid library to remove the last third-party runtime dependency.
Per-lab estimated reading time on cards, not just inside pages.

Frequently Asked Questions

Why static HTML instead of a framework?

Speed, durability, and full control over every tag. A portfolio of documents does not need a runtime. Static files cache perfectly, never break on a dependency update, and every crawler and AI agent reads the same bytes a human does.

How is the site deployed?

A push to main on GitHub triggers the Pages pipeline. Derived files (sitemap, feeds, search index, JSON endpoints, markdown mirrors) are generated by Python scripts and committed with the source. Cloudflare fronts the site for TLS, CDN caching, and headers.

What made the biggest performance difference?

Loading the Mermaid diagram library only on pages that actually contain a diagram. It was 680 KiB of JavaScript on all 197 pages; that single change took the homepage from 56 to 99 on Lighthouse mobile performance.

Does the site track visitors?

No. There is no analytics script, no cookie, and no third-party tracker, which is why there is no cookie banner. Speed and privacy are features here.

Cite This Page

Citation formats

Plain text

Taki Sadik, "How This Portfolio Is Built", TYFSADIK, https://tyfsadik.org/how-this-portfolio-is-built.html (accessed 2026-10-22).

BibTeX

@misc{sadik-how-this-portfolio-is-built,
  author  = {Sadik, MD. Taki Yasir Faraji},
  title   = {How This Portfolio Is Built},
  year    = {2026},
  url     = {https://tyfsadik.org/how-this-portfolio-is-built.html},
  urldate = {2026-10-22}
}

APA

Sadik, M. T. Y. F. (2026). How this portfolio is built. TYFSADIK. https://tyfsadik.org/how-this-portfolio-is-built.html