The 2026 Portfolio Page-Weight Benchmark: What Studio Sites Weigh

The Pattern

Using WebPageTest and public performance tooling across a sample of design studio home pages in early 2026, a clear pattern emerges. All tests used a simulated 4G mobile connection. The goal is not to name individual sites but to establish a realistic benchmark for what portfolio sites weigh in 2026 and identify the patterns that separate fast from slow.

The metrics tracked: total transfer size, number of requests, image weight, JavaScript weight, CSS weight, font weight, and time to interactive.

The Numbers

Median total transfer size: 3.4 MB

That is the home page alone. Not the entire site. Just the first page a visitor sees.

Lightest site: 340 KB. A static HTML and CSS site with a single hero image, no JavaScript framework, and self-hosted variable fonts.

Heaviest site: 18.7 MB. A React-based portfolio with an autoplaying background video, uncompressed hero images, and multiple third-party analytics scripts.

The distribution is heavily right-skewed. Most sites cluster between 2 and 5 MB, with a long tail of outliers above 8 MB.

Breakdown by resource type

| Resource | Median | Top quartile | Bottom quartile |

|----------|--------|-------------|-----------------|

| Images | 1.8 MB | 600 KB | 4.2 MB |

| JavaScript | 680 KB | 180 KB | 1.4 MB |

| CSS | 120 KB | 45 KB | 280 KB |

| Fonts | 180 KB | 60 KB | 420 KB |

| Video | 0 KB | 0 KB | 2.1 MB |

| Other | 140 KB | 80 KB | 320 KB |

Images dominate. They account for more than half the transfer weight on the median studio site. JavaScript is the second-largest contributor, and most of it comes from frameworks and third-party scripts rather than custom application code.

What the Fast Sites Have in Common

The sites in the top quartile (under 1.2 MB total) share several traits:

Modern image formats. Every fast site serves AVIF or WebP for photographic content. None of them serve uncompressed or high-quality JPEG as the primary format. The compression savings are enormous: a typical hero image at 1600 pixels wide weighs 200KB in JPEG and 60KB in AVIF at equivalent perceptual quality.

Minimal JavaScript. The fast sites either have no JavaScript framework or use a lightweight one. Static site generators with zero or near-zero client-side JavaScript produce dramatically lighter pages. The sites running React, Vue, or Svelte tend to ship 400KB to 1.2MB of JavaScript even for mostly static content.

Self-hosted and subset fonts. Fast sites host their own font files and serve only the character subsets they need. The heaviest font payloads come from sites loading multiple weights from Google Fonts without subsetting, pulling 300KB or more of font data for two typefaces.

No autoplaying video. Background video on portfolio home pages is the single largest weight contributor when present. Sites that use it are almost guaranteed to exceed 5 MB on the home page. The fast sites use static images or CSS animations instead.

Aggressive image sizing. Fast sites serve different image sizes for different viewport widths using srcset and sizes. They do not send a 3000-pixel-wide image to a mobile visitor. As we discussed in our earlier piece on image weight, responsive images are not optional for performance-conscious portfolio sites.

What the Slow Sites Have in Common

The bottom quartile (above 5.8 MB) shares a different set of patterns:

Full-resolution images everywhere. Hero images at 3000 to 5000 pixels wide, served as JPEG at quality 85 or higher, without responsive sizing. A single image can weigh 1 to 3 MB.

Framework overhead for static content. Sites built with React or Next.js (older versions without proper static optimization) that ship the full framework runtime for pages that have no client-side interactivity. The HTML, images, and text could be served statically, but the JavaScript bundle adds 500KB to 1MB of overhead.

Multiple analytics and tracking scripts. Google Analytics, Hotjar, Facebook Pixel, LinkedIn Insight Tag, and custom event tracking. Each script adds 30 to 100KB and often loads its own dependencies. Five tracking scripts can add 300KB to 500KB of JavaScript that provides no visitor-facing value.

Unoptimized video. Background video files encoded at high bitrate, sometimes without proper compression, sometimes without the playsinline attribute (causing full-screen takeover on mobile). Video is inherently heavy, but the difference between a well-encoded 30-second loop at 720p (800KB) and a poorly encoded one at 1080p (5MB) is substantial.

The Budget Framework

Based on this data, here is a reasonable page-weight budget for a portfolio site in 2026:

Target: under 1.5 MB total for the home page.

• Images: under 600 KB (use AVIF, responsive sizing, lazy loading below the fold)
• JavaScript: under 200 KB (framework + custom code + third-party scripts)
• CSS: under 80 KB (purge unused styles, use a utility framework or write lean CSS)
• Fonts: under 100 KB (self-host, subset, use variable fonts)
• Other: under 100 KB

This budget produces a page that loads in under 3 seconds on a 4G mobile connection and passes all Core Web Vitals comfortably. It is achievable with any modern static site generator and does not require gutting the visual design.

If you are building a project detail page with multiple high-resolution portfolio images, the image budget needs to be higher. But lazy loading below-the-fold images keeps the initial load weight manageable.

The Video Question

Should portfolio sites use video on the home page? The data suggests it is a costly choice:

• Sites with home page video: median total transfer 7.2 MB
• Sites without home page video: median total transfer 2.8 MB

That does not mean video is always wrong. But it means the decision should be intentional. If you use video, encode it properly (H.265 or VP9, 720p, 30fps, target 1MB or less for a 15-second loop), serve it conditionally based on viewport and connection speed, and provide a static fallback image.

Framework Choice and Weight

The framework or tooling choice has a measurable impact on page weight:

• Static HTML/CSS (no framework): median 800 KB
• Hugo/Eleventy/Astro (SSG, minimal JS): median 1.1 MB
• Next.js (static export, optimized): median 2.2 MB
• React/Vue SPA (standard): median 3.8 MB

The gap between a well-optimized static export and a standard SPA is roughly 1.5 MB, almost entirely JavaScript. That is not a condemnation of frameworks, but it is a reminder that framework choice has weight consequences.

FAQ

Is 3.4 MB really that bad?

For a home page, yes. On a 4G connection with 150ms round-trip latency, 3.4 MB takes roughly 6 to 8 seconds to fully load. First paint happens earlier, but the complete experience is delayed. Visitors on slower connections or metered data plans feel it even more.

Do clients care about page weight?

Most clients do not ask about it directly. But they notice when their site feels slow, when Google Search Console flags Core Web Vitals failures, and when analytics show high bounce rates on mobile. Page weight is the hidden cause behind all of those symptoms.

Is there a tool that tracks page weight over time?

SpeedCurve and Calibre provide continuous page weight monitoring. For a simpler approach, run WebPageTest on a schedule and track the total transfer size in a spreadsheet.

The Takeaway

The 2026 portfolio web is heavier than it needs to be. The median studio site ships 3.4 MB for a page that could communicate the same content in under 1 MB with modern formats, responsible image sizing, and minimal JavaScript. The fast sites prove it is possible. The gap between the fast ones and the slow ones is not about design ambition. It is about technical discipline.