Why we rebuilt befagency.com: from a 6-second load to 1.3 seconds

A web agency’s own site is its most visible reference. If we tell clients that “your site’s speed affects your sales”, our own site has to live up to it. In September 2026 we relaunched befagency.com with its new design. When the design was first finished it looked good, but the measurements told a different story: on a slow mobile connection, the service pages took about 6 seconds to show their largest content. In the version we shipped, that time is 1.3 seconds. This article explains what we measured and what we changed.

How we measured

We ran the tests in a Chromium-based browser emulating a slow mobile connection: 150 ms latency, 1.6 Mbps download and a 4x CPU slowdown. That is closer to a mid-range phone on 4G on the bus than to a good fibre connection. On every page we looked at three values:

• LCP (Largest Contentful Paint): the moment the largest image or text block appears on screen. Google considers anything under 2.5 seconds “good”.
• CLS (Cumulative Layout Shift): how much the content moves while the page loads. Under 0.1 is good.
• Total bytes downloaded: everything the phone downloads to open the page: HTML, JavaScript, images and videos.

Problem 1: the largest thing on screen was a video

At the top of our service pages, a video from one of our own shoots plays. For the browser, that video is the page’s “largest content”, but its first frame didn’t appear until the video file had downloaded and decoded. On top of that, the design’s intro animation kept the area invisible until JavaScript had loaded.

The fix took three steps: we gave every video a light cover image (poster), loaded that image with priority at the top of the page, and made the top content visible on first paint without waiting for the animation. Result: LCP on the service pages dropped from about 6 seconds to 1.3 seconds.

Problem 2: the home page weighed 7.8 MB

The home page has videos of our team and our work, client logos and a lot of photos. In the first build, most of it downloaded as soon as the page opened. What we did:

• Resized images to the size they are displayed at (1,400 pixels at most) and compressed them; PNGs that didn’t need transparency became JPEGs.
• Turned off autoplay for the work videos; a video file only downloads when the visitor plays it.
• Lazy-loaded the galleries below the fold.

The home page went from 7.8 MB to 2.4 MB. Layout shift during loading (CLS) dropped from 0.074 to 0.

Problem 3: the server wasn’t compressing the home page

This one only showed up on the live server. The server’s static-file acceleration bypassed Apache’s compression (gzip) and security headers for the home page request, so the home page HTML travelled to phones at 620 KB. After we fixed the rewrite rule, the same page is 81 KB. The same fix switched on HSTS and the other security headers for the home page.

Beyond speed: foundations for search engines and AI

Just as important as speed on the new site is that machines understand the content correctly. Alongside Google, AI systems such as ChatGPT and Perplexity read a page’s text and structured data when they recommend an agency. So:

• We added schema.org structured data: Organization, Service, BreadcrumbList, FAQPage on the home page, and BlogPosting with author details on articles.
• The site is in Turkish and English, and every page is linked to its counterpart with hreflang tags.
• We published an llms.txt file that summarises the site for AI systems.
• We added our own figures and frequently asked questions to the service pages.
• The sitemap updates with every release, and new articles are sent to search engines immediately via IndexNow.
• Cookie consent runs on Google Consent Mode v2; advertising cookies don’t run until the visitor consents.

Check your own site in 10 minutes

1. Enter your most important page into PageSpeed Insights (pagespeed.web.dev) and look at the mobile result.
2. If LCP is above 2.5 seconds, find which element is the LCP in the diagnostics. It is usually a cover image or a video.
3. If the total network payload is above 3 MB, look at the largest files; oversized images are the usual suspects.
4. Open the home page request in the Network tab of your browser’s developer tools. If you don’t see “content-encoding: gzip” or “br” in the response headers, your server may not be compressing.
5. The Core Web Vitals report in Google Search Console shows real-user data; compare your lab results with it.

If you’d like us to look at your site’s speed and technical setup together, see our web design and development page or get in touch.