Website Speed Optimization: Custom Fixes

Short answer: Website speed optimization means measuring where a page makes people wait, then fixing the responsible assets, browser work or backend code. Start with real-user evidence and repeatable tests on important journeys—not a promise of a perfect PageSpeed score, a plugin bundle or an automatic rebuild.

By Mohamed Samy, senior backend developer specializing in Laravel/PHP, with seven years of development experience. Published: 8 November 2026. Updated: 8 November 2026.

A product page appears quickly on an office laptop, yet its size selector sticks on a phone. An Arabic service page jumps when its font arrives. A booking form waits on an external service before responding. These are different failures. Compressing every image will not solve all of them, and buying a larger server may solve none.

For Egyptian companies serving local customers and expanding across the Gulf, the useful question is which part of the customer journey is slow, for whom, and why. Golden Code works on custom code and builds custom systems from scratch; we do not sell a ready-made speed product or a packaged theme. This guide explains how to commission measured performance work without confusing a score with a business result.

Public demand: testing terms and service intent

Google autocomplete checked on 8 November 2026 in Egypt returned “قياس سرعة الموقع”, “فحص سرعة الموقع جوجل”, “تحسين سرعة الموقع” and “سرعة تحميل الموقع” for the website-speed cluster. “core web vitals” returned test, checker, assessment failed and optimization variants. UAE suggestions for “website speed optimization” included services, test, tools and WordPress; the longer services query also returned a WordPress service variant.

Those suggestions show a mix of diagnostic and purchasing intent. They do not reveal search volumes, and a WordPress searcher is not automatically a buyer for custom development. This article is aimed at owners whose bottleneck needs code-level diagnosis or whose custom product has outgrown superficial changes.

The Trends API returned HTTP 429 during this check. No trend average or growth rate is reported. These public comparisons use a completed-week window: Egypt website-speed terms and UAE website-speed optimization. A measurable need is more useful here than manufacturing a breaking-news angle.

Know which number you are buying an improvement in

Google's Web Vitals guidance defines three user-experience metrics. The recommended “good” targets below are assessed at the 75th percentile, separately across mobile and desktop experiences. They are not promised results for your site.

Metric	What the visitor experiences	Good target	Typical investigation
LCP	Main image or text arrives	2.5 seconds or less	Server response, resource discovery, rendering
INP	A tap or click gets a visual response	200 milliseconds or less	Main-thread work, event handlers, third parties
CLS	Content stays in place	0.1 or less	Media dimensions, banners, fonts

A Lighthouse performance score is not the same thing as passing all three. Lighthouse's ordinary navigation test does not measure real-user INP; Total Blocking Time is a diagnostic proxy. A fast synthetic load can coexist with a slow product filter after the page opens.

Google's Search guidance recommends good Core Web Vitals, but speed work does not guarantee a ranking, traffic increase or sales percentage. Define success as a verified improvement in the affected experience while preserving essential functionality.

Lab tests, field data and the missing-data trap

PageSpeed Insights presents field data from the Chrome UX Report where available and a separate lab test. Before quoting a result, check whether the field section describes the exact URL or the entire origin. A healthy origin does not establish that your checkout is healthy.

CrUX methodology requires eligible, sufficiently popular pages and origins. Google does not disclose the exact popularity threshold. Missing CrUX data therefore does not mean a site is fast, slow or receiving a particular number of visits. Do not infer traffic from its absence.

For a site without usable field data, begin with repeatable lab tests and controlled interaction traces. Consider privacy-conscious real-user monitoring where appropriate, without collecting form contents or personal identifiers. Label synthetic results as synthetic. Record device, test conditions, URL, deployment version and whether caches were warm or cold so the next comparison means something.

Egypt first, then test the actual Gulf journeys

Start with the Arabic mobile landing page used in Egypt, then the service or product detail and the conversion action. Test the English version too. Arabic font files, text wrapping and RTL navigation can change the largest visible element and introduce layout shifts independently of the English template.

For Saudi Arabia and the UAE, test the advertised landing URLs and the relevant language, currency and delivery choices. Repeat this for Bahrain, Kuwait, Oman and Qatar wherever you serve customers. Do not assume all Gulf visitors share a network path, device or checkout flow; choose test locations based on your actual markets rather than a single fast desktop result abroad.

Compare query-string landing pages with the clean URL. Campaign parameters sometimes fragment a cache even when the content is identical. Any normalization must preserve required attribution and genuine content variations. If pricing or availability changes by market, the cache key must reflect that variation. Faster delivery is not an improvement when it serves the wrong price.

Diagnose LCP before changing every image

Google's LCP optimization guide, updated in March 2025, separates the metric into server response, resource load delay, resource load duration and element render delay. A smaller file can leave the total unchanged if JavaScript still hides the element until later.

Identify the actual LCP element per template. If it is the hero image, ensure the browser discovers it early in HTML and receives a correctly sized resource. Do not lazy-load the LCP image. Use a high fetch priority only for genuinely critical resources, not every picture on the page. Below-the-fold media can still load lazily.

If text is the LCP element, inspect font loading and render-blocking styles instead of blindly recompressing photos. Test Arabic glyph coverage and fallback metrics before removing font subsets or weights. Performance work that breaks the brand's Arabic typography needs another iteration, not a celebratory score screenshot.

On the backend, trace slow requests and database work before changing hosting. Repeated queries, synchronous external calls and unnecessary personalized rendering can delay the first byte. Queue work that does not belong in the response, but keep transaction outcomes honest: a “booking confirmed” message must not appear before the required reservation is actually secured. If runtime support is also a concern, our published PHP 8.2 end-of-life and Laravel upgrade plan covers that separate maintenance decision.

Fix interaction and stability without breaking the site

For an unresponsive filter, record the interaction rather than rerunning the home-page audit. Inspect event handling, rendering work and scripts competing on the main thread. Split unnecessary work, reduce the amount executed immediately and load optional features when needed. An animation that makes a button look active is not proof that the underlying operation responds correctly.

Third-party tags need named owners. Agree which analytics, consent, chat and advertising functions must remain. Do not simply delete them to produce a higher score, or delay consent processing in a way that changes privacy behaviour. Recheck events after each change so marketing does not discover a broken funnel later.

For CLS, reserve space for images, embeds and banners. Give media dimensions or an appropriate aspect ratio, and test font swaps and translated text. Content injected above the action button can shift the page at precisely the wrong moment. Test the real flow with banners visible, not just a fresh browser where the problematic state never appears.

Caching boundaries and repair versus rebuild

Cache public content where appropriate, but keep account-specific responses isolated. A product description, a signed-in price and a customer's cart are not interchangeable. Include tests proving that one customer cannot see another's information and that updates invalidate the right content. The exact cache design depends on the application, not a copied configuration.

A CDN can improve delivery distance and offload public assets; it cannot remove every slow database query or heavy browser task. Similarly, Laravel is not inherently a speed guarantee, and WordPress is not inherently the reason a page fails. An existing site may only need targeted repairs. Rebuilding is justified when measured constraints and maintainability support it, not because a framework is fashionable.

If the underlying product genuinely needs replacement, our custom website development cost guide covers a different decision: building a site rather than repairing its performance. Golden Code's custom development services cover code-level work; we do not position ready-made products as our offer.

We do not have a fixed package for performance work; any fee is a custom quote after we review the slow journeys, codebase and required access.

Six steps to commission measurable speed work

Step 1: Pick the journeys that matter

List the landing page, product or service detail, form and confirmation journey. Include Arabic and English where used. Record which step feels slow rather than handing over only a homepage score.

Step 2: Preserve a repeatable baseline

Save field-data scope where available, lab settings and interaction traces. Record deployment version and caching conditions. Compare like with like; do not call a desktop warm-cache run an improvement over a mobile cold-cache run.

Step 3: Rank causes and risks

Tie each proposed change to a bottleneck and expected metric. List functionality at risk, such as payments, consent and localization. Separate measured causes from hypotheses that still need tracing.

Step 4: Implement on a test copy

Make focused changes and rerun the relevant tests. Check forms, navigation, payments and account isolation. Keep rollback instructions, especially for cache and asset-delivery changes.

Step 5: Verify after an approved release

Compare the same pages and interactions under the same conditions. Check error logs and functionality as well as timing. Explain remaining constraints rather than selecting only the best successful run.

Step 6: Hand over a regression budget

Agree limits for assets and expensive interactions based on the application. Document who approves new scripts and oversized media. Separate immediate lab evidence from later field observations, and decide who investigates regressions.

FAQ

Can you guarantee a PageSpeed score of 100?

No. Agree measurable targets after diagnosis; synthetic scores vary and do not replace field experience or functional checks.

Why does PageSpeed show no real-user data?

CrUX has eligibility and popularity requirements. Missing data is not a performance verdict or a traffic counter; use repeatable testing and appropriate monitoring.

Should every image be lazy-loaded?

No. Google's LCP guidance explicitly warns against lazy-loading the LCP image. Prioritize the critical resource and defer suitable offscreen media.

Will a faster site automatically rank higher?

No. Google recommends good Core Web Vitals, but ranking depends on more than speed. No traffic, ranking or sales uplift is promised here.

Do I need to rebuild in Laravel to make the site fast?

Not necessarily. Diagnose first; targeted code and delivery fixes may be enough. A rebuild requires its own business and maintenance justification.

How is the work priced?

We do not have a fixed package for performance work; any fee is a custom quote after we review the slow journeys, codebase and required access.

Sources and a useful next step

Sources checked on 8 November 2026: Web Vitals definitions and thresholds, Google Search guidance, LCP optimization and CrUX methodology.

If a customer journey feels slow, share the affected public URL and the action that stalls. We can discuss the smallest useful custom scope before proposing a larger change.