Introduction

Modern web portfolios often rely on heavy JavaScript frameworks that bottleneck client-side rendering. The objective of this project was to engineer a fully static platform that strips away runtime overhead while maintaining interactive UI components. By leveraging static site generation and strict payload limits, this architecture eliminates main-thread blocking and strictly controls network payloads.

Technology Stack

The initial iterations of this platform utilized React and standard TypeScript. To achieve strict performance targets, the stack was migrated:

• Language: Svelte / TypeScript
• Framework: Astro
• UI Components: Svelte
• Build Tool: Vite
• Platform: Vercel

Rendering Architecture

The performance of this site hinges on how data is sent from the server to the browser.

Traditional Single Page Applications (SPAs) send a blank HTML file and a massive JavaScript bundle. The browser must download, parse, and execute megabytes of code before the user sees anything. This process—client-side rendering—hogs memory and drains mobile batteries.

Astro and Static Site Generation (SSG) Astro flips this model. During the build process (npm run build), Astro executes all the routing logic and component mapping on the server, generating raw, static HTML files for every page. When a user requests a URL, the server sends a fully formed HTML document. The browser paints it immediately.

Hydration HTML is static. To make components interactive (like a mobile navigation menu or tab toggles), JavaScript is selectively attached to specific HTML elements after they load. This is called “hydration.” Astro’s Islands Architecture allows me to leave 95% of the page as dead, zero-byte HTML, and only hydrate the exact components that require interactivity.

Svelte vs. JavaScript

Svelte is fundamentally different from traditional JavaScript frameworks like React or Vue. React is a runtime library; you must force the user to download the React engine so the browser can figure out how to update the DOM on the fly.

Svelte is a compiler. It does its work during the build step, analyzing the code and compiling it down into highly optimized, vanilla JavaScript instructions. There is no virtual DOM and no framework runtime shipped to the client. This results in significantly smaller file sizes and faster execution times.

Infrastructure & Deployment Pipeline

The hosting and deployment pipeline is fully automated and geographically distributed:

1. Domain & DNS: The domain was purchased through Dynadot. The nameservers were pointed to Cloudflare to manage DNS records, providing a layer of security and fast DNS resolution.
2. Hosting: The platform is hosted on Vercel.
3. CI/CD: The GitHub repository is linked directly to Vercel via GitHub Actions. Pushing code to the main branch triggers an automated Vite build.
4. Edge Delivery: Vercel distributes the compiled static HTML and compressed assets across its global Edge CDN (Content Delivery Network). This physically positions the website data on servers close to the user, cutting latency down to milliseconds.

Performance Benchmarks

Static site generation drops the active server memory usage of this platform to 0 MB, as there is no backend process running; the server merely hands over pre-built files. On the client side, a Chrome Heap Snapshot reveals the site consumes approximately 5.5 MB of memory, a fraction of standard web applications.

Network Optimization: The 14kB Rule

When a browser connects to a server, it does not download the entire site at once. Due to TCP Slow Start, the server cautiously sends data in small chunks (packets) to test the network’s capacity. The initial congestion window allows for exactly 10 packets, which equates to roughly 14 kilobytes (14kB) of data.

If the critical files (HTML and CSS) fit within this 14kB window, the browser can render the site in a single Round Trip Time (RTT). If they exceed it, the browser must request more data, doubling the latency.

Network Latency Table

RTT #	Data Transmitted per RTT	Max Cumulative Data Received	Cumulative 3G Latency	Cumulative 4G Latency	Cumulative 5G Latency
1	14.6 kB	14.6 kB	150 ms	50 ms	10 ms
2	29.2 kB	43.8 kB	300 ms	100 ms	20 ms
3	58.4 kB	102.2 kB	450 ms	150 ms	30 ms
4	116.8 kB	219.0 kB	600 ms	200 ms	40 ms
5	233.6 kB	452.6 kB	750 ms	350 ms	50 ms
6	467.2 kB	919.8 kB	900 ms	420 ms	60 ms
7	934.4 kB	1.85 MB	1.05 ms	490 ms	70 ms
8	1.87 MB	3.72 MB	1.20 ms	560 ms	80 ms
9	3.74 MB	7.46 MB	1.35 ms	630 ms	90 ms
10	7.48 MB	14.93 MB	1.50 ms	700 ms	100 ms

Gzipped Build Outputs

By purging the React runtime and compiling with Svelte, the core assets fit well within the earliest TCP windows:

• index.html (~7.5 kB): Delivered in RTT 1. The browser immediately knows what to draw.
• experience.[hash].css (~17.0 kB): Pushed in RTT 2. The layout is fully styled. First Contentful Paint (FCP) fires.
• render.[hash].js (~13.0 kB): Arrives in RTT 2.
• Navigation.[hash].js (~10.5 kB): Arrives in RTT 2. The interactive UI is hydrated.

The 16:9 desktop hero image (GradPic16x9-50.webp at 205 kB) loads asynchronously by RTT 5, triggering the Largest Contentful Paint (LCP) well under standard network latency thresholds.

Google Lighthouse

The site is optimized not just for humans, but for machine interaction. It scores a 2/2 on Google’s Agentic Browsing metric, providing a curated llms.txt file, structured accessibility trees, and zero layout shifts to allow AI agents to parse the engineering data without friction.