Skip to main content
.com domains from $2.99 — free WHOIS privacy on every name

LCP brief · Estate Agency Sites

Web hosting for real estate agents — Twenty photographs, and only one of them is your problem

A listing page is judged on the first image a vendor sees, not on the nineteen below it — and most agency sites are optimising the wrong nineteen.

The short answer

Find the LCP element before you touch anything: on a listing page it is almost always the first gallery photograph, and it is the only image on the page whose weight affects your Largest Contentful Paint at all. The other nineteen should be lazy-loaded, which means they download as the visitor scrolls and cost nothing on the initial measurement. Get that division right and a twenty-image listing performs like a one-image page.

The published target is LCP at or under 2.5 seconds at the 75th percentile. WebP conversion is built into the platform and images load progressively, so only the frames on screen actually download — leaving you the two decisions that matter: dimensions, and which single image is eager.

By the HostingFast team · Reviewed 24 August 2026

Free

Migration, handled by us

24/7

Answers, day and night

Daily

Restore points created

$0

Onboarding charge

Agency sites are structurally the same page repeated: one listing template, a few hundred instances, each carrying heavy photography. That makes template-level work extremely high leverage and page-level work almost worthless.

It also makes the diagnosis unusually clean. Buyers find properties on the portals, but vendors judge the agent by their own website, and the vendor's visit starts with a listing page loading on a phone. One image decides how that visit feels.

There is a second, quieter performance story on these sites: the feed import. Portal synchronisation writes to the database on a schedule, and a badly-scheduled import competes with the visitors it exists to serve. Both stories are below.

Identify the element, then size it

Run a Lighthouse audit in Chrome DevTools on a representative listing, throttled to a slow mobile profile, and read which element it names as the LCP element. Then find that image in the network panel and compare its intrinsic dimensions against the size it renders at. A 3000-pixel photograph in a 700-pixel column is the single most common finding on an agency site.

Fix it precisely rather than broadly. Serve that one image at roughly twice its displayed width to cover high-density screens, keep it eager, and let the platform's automatic WebP conversion handle the format. Then re-run the audit and confirm the named element and its size have both changed — otherwise you optimised something the browser was never waiting on.

The other nineteen should cost nothing

Every image below the fold should be lazy — the browser defers the download until the visitor scrolls towards it, so a twenty-image gallery transfers two or three images on an initial load rather than twenty. Confirm it rather than trusting a theme setting: reload the page without scrolling and count the image requests in the network panel.

Reserve their space, though. A gallery that lazy-loads without width and height attributes shifts the layout as each image arrives, which is exactly what Cumulative Layout Shift measures — the target is under 0.1 at the 75th percentile. Reserved dimensions cost nothing and remove the problem entirely.

The feed import is a write workload

Portal synchronisation is the part of an agency site that behaves least like a website. It reads a feed, writes property records, and generates image derivatives — all of it uncacheable, all of it competing for the same resources as the visitor reading a listing at the same moment.

Schedule it off-peak and check what triggers it. WordPress's scheduler fires on visitor requests by default, which means a heavy import can be kicked off by somebody browsing your site and executed while they wait. Moving it to a real system cron on a fixed schedule is a small change with a disproportionate effect, and SSH with Git and Composer ships on shared plans so WP-CLI can run it directly.

Prove the template got faster

Because every listing shares the template, verify across the set rather than on the page you tuned. Sample four or five other listings after the change and confirm the same improvement appears. Where one lags, that listing has something the others do not — an oversized image uploaded by hand, usually — and you have found it cheaply.

Then wait for the field report. It reads a rolling 28-day window of real visits and grades LCP at or under 2.5 seconds and CLS at or under 0.1 at the 75th percentile. A lab improvement that never shows up there did not reach a vendor, and on a site this template-driven it almost always does.

A team planning the next release of their business site

What the platform does for a heavy gallery

Images convert to WebP automatically and load progressively, so only the frames on screen actually download, and LiteSpeed serves the whole listing page from cache once it has been rendered.

NVMe storage sits under the feed import as well as the reads, so the write workload that keeps your listings current is not queueing behind a slow disk. SSH and WP-CLI let you schedule it properly.

  • Automatic WebP conversion on uploaded photography
  • Progressive loading, so off-screen frames wait
  • NVMe storage under the feed import's writes
  • SSH with Git and Composer for scheduled tasks

Why HostingFast

Standard on every plan

One image to get right

Naming the LCP element turns a twenty-photograph page into a single decision about dimensions and loading priority.

Format conversion handled

Automatic WebP means the remaining variable is what you upload, which is the one part of the pipeline you can control exactly.

Template leverage

Every listing shares the build, so one correction propagates across the whole portfolio at the moment you save it.

A place for the import to run

NVMe under the writes and SSH for real scheduling, so feed synchronisation stops competing with the vendor reading a listing.

A rollback for a bad import

Daily backups recover files, a database or both from the panel — useful when a feed import writes something you did not intend.

A migration with a before and after

Engineers move the account at no cost and you sign off before DNS switches, so the move gets a before and after number of its own.

Quick Start

From order to online

  1. 1

    Name the LCP element

    Throttled Lighthouse run on a representative listing. Do not guess which image it is — the report tells you, and it is occasionally not the one you expected.

  2. 2

    Size that one image properly

    Roughly twice its displayed width, eager, WebP handled by the platform. Then confirm the audit names a different element or a smaller one.

  3. 3

    Verify across five other listings

    Template work has to be checked at the set level. Any listing that did not improve has something specific wrong with it, which is a useful thing to find.

Built In

Loaded onto every plan

  • LCP element named by a throttled Lighthouse run, not assumed
  • That image's intrinsic dimensions compared against its displayed width
  • Exactly one eager image per listing; the rest lazy-loaded
  • Image requests counted on an unscrolled reload to confirm laziness
  • Width and height attributes present so lazy images reserve their space
  • Cumulative Layout Shift checked against the 0.1 threshold
  • Automatic WebP conversion left on to handle format
  • Feed import moved to a real cron schedule rather than visitor-triggered
  • Import timed off-peak so writes do not compete with reads
  • The improvement verified on five further listings, not just the tuned one

Frequently Asked

What people ask us most often

How do I find out which element is the LCP element?

Run Lighthouse in Chrome DevTools with the network throttled to a slow mobile profile; the report names the element explicitly. Do not infer it — on listing pages it is usually the first gallery image but it can be a map tile, a hero video poster or even a block of text if the images are slow to be discovered. Optimising the wrong element is the most common wasted afternoon in this work.

Should the whole gallery be lazy-loaded?

Everything except the image the browser paints first. Lazy-loading the LCP element is the classic self-inflicted failure: you have told the browser to defer the one thing the measurement is waiting for. Keep the first image eager, lazy the rest, and confirm by reloading without scrolling and counting the image requests that actually fire.

Our feed import slows the site down. What is the fix?

Two changes. Move it off visitor-triggered scheduling to a real system cron, so an import is never executed inside somebody's page request, and run it off-peak. SSH with Git and Composer ships on shared plans, so WP-CLI can drive the import directly on a fixed schedule. If the import also generates image derivatives, that is the part worth timing — it is usually the expensive half.

Why does one listing score much worse than the rest?

Because somebody uploaded an image by hand at full resolution, or that listing has more gallery frames above the fold than the template intends. Template-driven sites are consistent by design, so an outlier is almost always a content exception rather than a code one. That makes it quick to find and quick to fix once you are checking at the set level.

Keep reading

Changing hosts? Run through our checklist first.

A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.

You'll get the checklist email, then occasional pointers on keeping a site running fast. Unsubscribe the moment you want out — the privacy policy covers the rest.

One image, one template, one number.

Automatic WebP conversion, progressive loading, NVMe under the feed writes, and SSH so the import runs on a real schedule.

View Ecommerce Hosting — Built for Estate Agents plans