Your Event Portfolio Is What Makes Your Site Slow. Here Is the Fix

Event photography is almost always the heaviest thing on an event company website, and weight is what makes a site slow. One unoptimised hero image from a photographer’s delivery folder can outweigh every other file on the page combined, and a gallery stacked with dozens of them is not a portfolio, it is a download. The work is beautiful. The delivery is broken.

The fix is not to show less work. It is to stop shipping camera-original files to phones, tell the browser the size of every image before it arrives, load what is below the fold only when someone scrolls to it, and stop letting third-party widgets tax every page. None of this changes what a visitor sees. All of it changes how fast they see it.

This guide walks through the causes in the order they usually matter, with the checks you can run yourself. The pattern is consistent across event planners, production companies and event management firms: the better your photography, the more likely your site is slow.

The phone at the venue walkthrough is the real test

Your website is most often judged on a phone, in a building with bad signal, by someone with about a minute to spare. A venue coordinator is deciding whether to recommend you. A corporate events manager is checking you between sessions. A couple is standing in a ballroom with a competing planner’s tab already open.

Where the judgement actually happens

The contexts in which someone first opens your site are rarely a desktop with fast wifi:

• During a venue walkthrough, on venue wifi shared with a load-in crew and a hundred other devices.
• Between sessions at a conference, on cellular in a building designed to absorb radio signal.
• In a comparison tab group, where three planners’ sites are open and the slowest gets closed first.
• From a referral text, tapped while someone is doing something else.

In each of those, the site that becomes usable first has an advantage unrelated to which company is better at running events. That is the most fixable disadvantage on this list.

Why photography is the specific problem

Photography is the one asset class event companies refuse to compromise on, and rightly so. But there is a large gap between quality and file size, and most event sites pay for file size without gaining quality.

A photographer’s delivery is made for print: very large pixel dimensions, minimal compression, embedded colour profiles and metadata. A phone displays a fraction of those pixels. Uploading it means the visitor downloads every pixel they will never see, then waits while their browser scales it down to something it could have received in the first place.

What Core Web Vitals actually measure, in plain language

Core Web Vitals are three measurements Google uses to describe how a page feels to a real person: how fast the main content shows up, how fast the page reacts when you touch it, and how much the layout moves while loading. According to web.dev, they are assessed at the 75th percentile of real page loads, with mobile and desktop assessed separately, which is why a site that feels fine on your laptop can still be failing the audience that matters.

Largest Contentful Paint: how fast the main thing appears

LCP measures the time until the largest visible element in the viewport has rendered, which on an event company homepage is nearly always the hero photograph. web.dev documents a good LCP as 2.5 seconds or less, measured from when the page starts loading.

This is the metric your portfolio hurts most directly. If the hero is a huge file, or the browser finds it late because a script loads it or a slider hides it, LCP suffers no matter how fast the rest of the page is. Three things fix it: make the hero smaller, make sure the browser finds it early, and do not lazy-load it.

Interaction to Next Paint: how fast the page answers a tap

INP measures how long a page takes to respond visually after an interaction, such as tapping a gallery thumbnail or opening a mobile menu. web.dev documents a good INP as 200 milliseconds or less.

Poor INP usually traces back to JavaScript rather than images: a heavy gallery library, a lightbox that initialises every image on page load, a chat widget booting up, or tracking scripts competing for the main thread at the moment the visitor taps something. Visitors describe it as “it froze for a second,” and they blame your company for it.

Cumulative Layout Shift: how much the page jumps

CLS measures unexpected movement of visible content while a page loads, and web.dev documents a good CLS as 0.1 or less. Anyone who has tried to tap a link and hit an advert instead has experienced bad CLS.

Photo-heavy pages are the classic cause. When an image arrives with no declared dimensions, the browser reserves no space, lays out the text, then shoves everything down when the image loads. Multiply that by a full gallery and the page behaves like it is being rebuilt underneath the reader.

Get the formats and the sizes right

Two decisions govern how heavy an image is: the format you save it in, and the pixel dimensions you send to a given screen. Most event sites get both wrong at once.

Choose the format by what the image contains, not by what your camera or design tool happened to export. Modern formats such as WebP and AVIF produce substantially smaller files than JPEG at visually comparable quality for photographic content, and the browser can be offered several options and left to pick the one it supports.

Format by content type

• Event photography, portraits, venue shots, room sets. AVIF or WebP, with a JPEG fallback for older software. These are continuous-tone images, which is what those formats are built for.
• Logos, sponsor marks, icons, simple diagrams. SVG. It is vector, so a sponsor logo wall built from SVG is trivially light compared with the same wall in PNG.
• Screenshots and images with sharp text. WebP. Avoid JPEG here, which blurs hard edges and produces halos around text.
• Anything needing transparency. WebP and AVIF both support it, so there is rarely a reason to reach for a large PNG.

MDN’s documentation on the picture element describes how to offer several formats and let the browser choose, which is what makes format modernisation safe rather than risky.

Stop uploading the delivery folder

The most common mistake is uploading what the photographer sent. Your website needs a web derivative: resized to the largest dimension the layout will ever display, exported in a modern format, with metadata stripped and the colour profile converted for the web.

Make this a rule for whoever uploads content, or it will be undone within a month of launch. The reliable version is images processed automatically on upload so nobody has to remember, which our features page covers. Where uploads are manual, write the export settings down next to the upload instructions.

srcset and sizes, explained without jargon

A phone should never download a desktop-sized image, and responsive images are what prevent it. MDN’s documentation on the img element describes two attributes that do the work. The first, srcset, lists the same image at several widths, each labelled with its pixel width. The second, sizes, tells the browser how wide the image will display at different screen widths, so it can choose before it has finished laying out the page.

Both are needed because of timing: the browser starts fetching images before it knows the final layout, so you describe the intent in advance. Get sizes wrong and it picks a file that is too large, wasting the exercise, or too small, which looks soft.

A sensible size ladder for event photography

Generating each image at a small set of widths covers every realistic device without creating an unmanageable asset library:

1. A small width for gallery thumbnails and mobile list items.
2. A medium width for single-column mobile heroes and full-bleed mobile sections.
3. A large width for tablet and standard desktop display.
4. An extra-large width only for full-bleed desktop heroes on wide screens.

Generate these automatically. The manual version lasts exactly as long as the person who set it up stays interested.

Width and height attributes stop the page from jumping

Setting width and height attributes on every image is the cheapest fix available, and most portfolio pages skip it. They let the browser calculate the aspect ratio and reserve the right space before the file arrives, so nothing moves when it does.

What actually causes the jump

Layout shift on an event site comes from a small set of repeat offenders:

• Gallery images with no dimensions, the big one on any portfolio page.
• Web fonts that swap in late, changing line heights and pushing sections down as headings reflow.
• Announcement bars and cookie banners injected after the content has already rendered.
• Embedded social feeds and review widgets that arrive at an unknown height and expand once loaded.
• Sponsor logo rows built from many small images that each load at their own pace.

For the ones you control, declare dimensions. For the ones a third party injects, reserve a fixed block of space so their arrival fills a hole rather than creating one.

The rule to enforce

Every image element carries a width and a height attribute matching the file’s real pixel dimensions, and CSS handles responsive display from there. No exceptions, including images added to posts and case studies later.

Loading strategy: eager hero, lazy everything else

Load the hero image eagerly and let everything below the fold load lazily. Portfolio pages frequently get this backwards, applying lazy loading to every image including the one that defines LCP.

The hero is the exception

The hero is the largest contentful paint on most event pages. Lazy loading it tells the browser to wait, delaying the exact thing the metric measures. It should be a normal, eagerly loaded image the browser can discover early in the markup, ideally with a preload hint so the fetch starts before the stylesheet finishes parsing.

Avoid putting the hero inside a JavaScript-built slider. That hides it from the browser’s early scan, and a rotating hero rarely earns its cost when the visitor is deciding within seconds.

Everything below the fold

MDN documents the loading attribute on the img element, which tells the browser to defer fetching an image until it is near the viewport. Apply it to gallery images, case study photography, team headshots, sponsor logos and anything else not visible when the page first renders.

The effect on a long portfolio page is large: it converts a page that downloads an entire gallery at once into one that downloads the visible images and fetches the rest as the visitor scrolls.

Galleries, lightboxes and infinite scroll

Galleries are where good intentions go wrong. Three patterns are worth checking.

• A lightbox that preloads full-resolution versions of every thumbnail on page load. Common and very expensive. Load the full version when the thumbnail is clicked.
• A masonry or grid library that recalculates layout on every image load. This shows up as poor INP on mobile, where the processor has less headroom.
• Infinite scroll on a portfolio. It feels modern and it prevents the visitor ever reaching your call to action. Paginate, or split the gallery by event, and give the page an ending.

Video, embedded players and the highlight reel

Video is worth including when the visitor chooses it and expensive when it plays at them. That distinction is the whole decision.

Background hero video

Autoplay background video on a homepage hero is the performance decision event companies most often regret. On a phone it competes for bandwidth with the images the visitor actually needs, drains battery, and is usually muted and ignored. If the brand genuinely requires motion, use a short, heavily compressed, muted loop behind a poster image that displays immediately, and disable it on small screens and on connections the browser reports as slow.

Embedded players

A standard embedded player loads a substantial amount of script before anyone presses play. The fix is a facade: show your own poster image with a play control and load the real player only after a click. The experience is identical and the cost moves from everyone to the people who wanted the video.

The same applies to galleries embedded from a photography platform, which hand your page weight to a company with no stake in your Core Web Vitals. Host your own portfolio and link out to the full client gallery instead.

Third-party widgets and what they really cost

Third-party scripts are the second heaviest thing on most event company sites, after images, and the least audited. Each arrives with a justification and none of them ever leave.

The usual suspects

• Chat widgets. Frequently the largest single script on the page. Load on click, or after the page is interactive, rather than on first paint.
• Booking and scheduling embeds. Genuinely useful, but they belong on the page where booking happens, not sitewide in a footer.
• Social feed embeds. Often the worst value on the page. They load a lot, they shift the layout, they sometimes break, and they send visitors away. A curated set of your own images achieves the same visual goal.
• Review and testimonial widgets. Same pattern. Pull the content in at build time and render it as plain markup instead of loading a third-party app.
• Tag managers and pixels. They multiply quietly, and usually nobody can say what half of the tags inside do.

An audit you can run this afternoon

1. Open your homepage in developer tools, on the network tab, with the cache disabled.
2. Sort requests by size and write down the largest ones.
3. Sort by domain and list every domain that is not yours.
4. For each external domain, name the owner and the purpose. Anything you cannot name goes on the removal list.
5. For each one that stays, decide whether it needs to load sitewide or only on one page.
6. Re-test and compare the number of requests and the total transferred weight.

Most event companies find a couple of scripts nobody has thought about since an old marketing experiment. This audit is a standard step in a website redesign, because it is easier to decide what belongs on a site while rebuilding it than while defending it.

Organise the portfolio by event type so pages stay small

The structural fix for a slow portfolio is to stop having one enormous portfolio. Splitting the work by event type keeps every page small, and it is better for the visitor and for search at once.

Category pages instead of one mega-feed

A single feed containing every image from every event is heavy to load and hard to use. A corporate events manager scrolling past wedding photographs to find a general session shot is working for something you should have handed them.

Split the portfolio into the event types you run, each with its own page: weddings and social events, corporate and conference work, festivals and experiential builds, nonprofit galas and fundraisers. Each page then carries only its own images, which caps the weight naturally. A wedding-focused site and a festival and experiential site end up with very different galleries, and neither should pay for the other’s weight. The reasoning behind this split is covered in our post on the run of show method for event company websites.

A case study is not a photo dump

An individual event page should carry a tight edit, not the full delivery. A dozen to twenty images showing scope, scale, room sets, load-in complexity and the finished result do more work than hundreds of frames of the same ballroom.

A useful discipline: for each image, say in one sentence what it proves. Anything that does not prove something distinct comes out. The page gets lighter and more persuasive at once, which is the approach we take when building event planner websites.

A monthly check routine

Check performance monthly, on a fixed date, using the same pages and tools each time so you are comparing like with like. A site rarely gets slow in one dramatic event. It gets slow one upload at a time. Our own builds target a 90+ PageSpeed result, and that target stays met only because it is re-checked, not because it was hit once at launch.

The short version

1. Run a speed test on three pages: the homepage, your busiest event type page, and your busiest case study.
2. Record LCP, INP and CLS for each, in a running note, alongside the date.
3. Check the largest file on each page. A new image at the top of that list means someone uploaded a delivery file.
4. Check the count of external domains. If it has gone up, something was added without a conversation.
5. Open each page on your own phone on cellular, not wifi, and scroll it. Numbers are useful; the feel of the page is the product.

What to do when a number moves

If LCP worsens, look at the hero image first, then at anything newly added above the fold. If CLS worsens, look for a new widget or an image without dimensions. If INP worsens, look for a new script rather than a new picture. In almost every case the cause is something added since the last check, which is what makes a monthly check cheap. Waiting a year turns a short diagnosis into a rebuild.

What to do next week

Pick the three pages that matter most and fix them properly rather than doing the whole site at once. That is one week of work.

1. Monday. Run the speed test and the network audit on those three pages. Write the numbers down so you have a before.
2. Tuesday. Re-export their hero images as proper web derivatives in a modern format, at the largest size the layout displays.
3. Wednesday. Add width and height attributes to every image on those pages, and lazy-load everything below the fold while leaving the hero eager.
4. Thursday. Deal with the third-party scripts. Move the chat widget to load on click, remove anything nobody can justify, and restrict booking embeds to the booking page.
5. Friday. Re-test, record the after, and write the export settings into your content guidelines so the next upload does not undo the work.

If that describes a project you would rather not own, it is the kind of thing a managed plan absorbs: images processed on upload, dimensions enforced in the markup, and a performance target maintained rather than hit once and forgotten. Our pricing page sets out what each plan covers, and you can book a demo to walk through your portfolio pages and see which of these problems your site actually has.