Modeling Portfolio: The Website Half Nobody Talks About

A modeling portfolio is now a website first and a printed book second, and the website is the part every guide skips. Which shots to include is well covered. Whether a booker can open it on their phone in a taxi, on a domain that is yours rather than a platform’s, is not.

The photography advice out there is good. Categories, digitals, a strong opener, a range that shows what you can be cast as. What almost nobody covers is that the thing carrying those images is a website with an address, a load time, and a monthly cost, and that those three details decide whether the work gets seen at all.

What actually goes in it
The domain question, which is the real decision
Image weight, and why it decides everything
Bandwidth is the line item that surprises people
What the site needs to do besides look good
Keeping it current without rebuilding it
How this fits the rest of the stack
FAQ

What actually goes in it

Briefly, because this part is well documented and the rest of the page is not.

Digitals or polaroids: clean, unretouched, natural light, hair down, minimal makeup, front, profile, and full length. Agencies want these first and they want them recent.
A headshot that looks like you on a normal day rather than the most stylised image in the set.
Full-length shots that show proportion honestly.
Range across the categories you are actually going for — commercial, editorial, fitness, beauty — rather than every genre you have ever shot.
Your stats: height, measurements, hair, eyes, shoe. Text on the page, not baked into an image.
Contact details, or your agency’s.

Fifteen strong images beats forty inconsistent ones. A booker forms a view in about eight seconds and the weakest image in the set is the one that sticks. Cut anything you are unsure about.

One practical detail with technical consequences: put your stats in real text, not inside a JPEG. Text can be selected, copied into a casting form, read by a screen reader, and found by search. An image of text can do none of those.

The domain question, which is the real decision

Portfolio platforms are convenient and they give you an address that belongs to them. A URL of the form yourname.someplatform.com is theirs, permanently. Every business card, every casting submission, every agency profile that links to it is pointing at an asset you rent.

This matters in three specific ways. Platforms change their pricing, and you either pay or your portfolio goes offline. Platforms shut down, and there is no forwarding address. And a platform subdomain builds search presence for the platform rather than for your name.

Registering yourname.com costs about the same as a coffee once a year and solves all three. Point it at whatever hosts the site today, and if you move to something else in two years, you repoint the domain and every link that ever existed keeps working.

Most platforms allow a custom domain on a paid tier. Use it. The version of this decision you regret is the one where the domain is available now, you skip it, and someone else takes your name later.

Register the obvious variants if the name is common — the .com plus your country’s extension is usually enough. Do not buy fifteen. Point the extras at the main one with a redirect.

Image weight, and why it decides everything

A modeling portfolio is almost entirely photographs, which means it is one of the heaviest kinds of site there is, and it is opened disproportionately on phones over mobile data. That combination is where portfolios quietly fail.

A single unprocessed image straight from a photographer can be 8MB. Twenty of them is 160MB. On a good connection that is slow; on a train it does not finish. The visitor does not report a bug, they close the tab, and you never learn it happened.

The fix is not complicated:

Resize to what is actually displayed. A full-width image on a phone needs about 1600 pixels wide, not 6000.
Export as WebP or AVIF with JPEG fallbacks. Both cut file size substantially at the same visual quality.
Use srcset so phones download a small file and desktops a large one, rather than everyone downloading the largest.
Lazy-load everything below the first screen so the opening image appears immediately.
Set explicit width and height on every image so the layout does not jump as they arrive.

A well-prepared portfolio page can carry twenty images in under two megabytes and open in a second or two on a phone. The same twenty images unprocessed will take twenty times that. Nobody looking at the finished pages can tell the difference in quality, and everybody can tell the difference in speed.

Bandwidth is the line item that surprises people

Hosting a portfolio is cheap. Serving it can be less cheap, and the reason is bandwidth, which is the only cost that scales with attention.

The arithmetic is worth doing once. If a page weighs 3MB and a thousand people view it in a month, that is 3GB of transfer. Trivial. If the page weighs 30MB because the images were never processed, the same thousand visitors cost 30GB. Still probably fine. Now imagine one shoot gets shared widely and fifty thousand people look. At 3MB that is 150GB; at 30MB it is 1.5TB, and that is the difference between an unremarkable month and a bill worth reading twice.

This is exactly why image optimisation is a cost decision and not a perfectionist one. The same work that makes the site fast makes it an order of magnitude cheaper to serve, and it is done once.

For reference on the shape of it, static site hosting on RunxBuild includes 120GB of bandwidth and charges $0.10 per GB beyond that — so a well-optimised portfolio sits comfortably inside the included allowance even after a good month, and an unoptimised one is what turns a quiet plan into an invoice.

What the site needs to do besides look good

A handful of things separate a portfolio that works from one that merely exists.

Load fast on a phone on mobile data. This is the whole game and it is decided by image weight.
Work without JavaScript for the basics. Some agency networks and email previews are conservative; a portfolio that renders nothing without scripts renders nothing for them.
Have a real page title and description. It appears in search results and in every link preview when someone shares it in a message.
Include contact details as text, not only in an image or a contact form that may be broken.
Serve over HTTPS. A browser warning on a personal site reads as amateurish before anyone has seen a photograph.

Add a downloadable PDF version of the composite card. Some bookers still want a file they can attach to an email, and providing one saves an exchange.

None of this requires a developer. It requires knowing that these are the criteria, which is the part the photography-focused guides do not tell you.

Keeping it current without rebuilding it

A portfolio is only useful if it reflects recent work, and the reason most go stale is that updating them is annoying. Design for the update, not just the launch.

Whatever you build on, the test is whether adding six images from last week’s shoot takes ten minutes or an evening. If it takes an evening, it will not happen, and in eighteen months the portfolio will be showing work that no longer represents you.

A static site built from a folder of images and a simple content file passes this test well: you add the files, push, and the site rebuilds. A hand-coded page where every image is a block of HTML you edit by hand does not.

Keep the originals somewhere safe and separate from the website. The site should carry processed, web-sized copies; the full-resolution files belong in storage you control, because a photographer’s link expires and a platform you leave does not hand your archive back.

How this fits the rest of the stack

The photographs are the work. The site is a delivery mechanism, and it fails in boring ways — a platform subdomain you do not own, images too heavy to open on a phone, a page nobody has updated in two years. Getting those three right costs a domain registration and one afternoon of image processing. If you are choosing where the site itself lives, the RunxBuild hosting calculator shows the static hosting and bandwidth as separate numbers, which is the honest way to look at a site that is mostly photographs.

Useful related references:

FAQ

Do models need their own website, or is a platform enough?

A platform is fine to start and gets you online quickly. What it does not give you is the address. Attach your own domain as soon as you can, even while staying on the platform, so that every link you hand out keeps working when the pricing changes or the platform closes. The domain is the part worth owning.

How many photos should a modeling portfolio website have?

Around fifteen to twenty strong images, organised by category. A booker decides in seconds and the weakest image is the one that lingers, so cutting is more valuable than adding. Include recent digitals — clean, unretouched, natural light — because agencies look for those before anything stylised.

Why is my portfolio site so slow on mobile?

Almost certainly image size. Unprocessed photographs can be several megabytes each, and twenty of them on one page will not finish loading on mobile data. Resize to display width, export as WebP or AVIF, use srcset so phones fetch small files, and lazy-load anything below the first screen.

How much does it cost to host a modeling portfolio?

The hosting itself is inexpensive for a static site. The variable is bandwidth, which scales with how many people look and how heavy your pages are. A well-optimised portfolio stays within a typical included allowance even after a busy month; an unoptimised one can use ten times the transfer for identical-looking pages.

Should I put my measurements as text or in an image?

As text. Text can be copied into a casting form, read by a screen reader, and indexed by search engines. Measurements baked into a JPEG can do none of those, and they also become unreadable when the image is scaled down on a phone.