Optimize speed & delivery
Fix the slowest meaningful experience, then re-measure.
Core Web Vitals describe loading, responsiveness and visual stability. Lab tests diagnose; real-user field data reflects actual visits and may be unavailable on small sites. Faster pages help users, but a perfect lab score does not guarantee recommendations.
Your implementation route
Use Wix image delivery and responsive image options, remove unnecessary apps and embed scripts, and check the published mobile page. Wix controls the underlying server and cache; Nginx/PHP examples are not files you can paste into the editor.
Platform boundaries & account requirements
Use Wix's native integrations and SEO & GEO tools. Backend examples belong in a supported Wix backend module or an external service, never in a page embed.
Open Wix ↗A representative mobile page, a before measurement, image sources and control of the relevant template or host settings.
Follow the steps
Check only after completingMeasure before editing
Run PageSpeed Insights on homepage, a revenue page and a conversion page. Record field data when available and the lab test conditions. Prioritize the actual LCP element, long tasks and visible layout shifts instead of optimizing a score in isolation.
Fix the first screen
Give images dimensions, use responsive modern formats and avoid lazy-loading the main hero/LCP image. Reduce unnecessary fonts and large animation libraries. Defer nonessential embeds and load them only when needed.
Apply caching to the right content
Use long immutable caching only for fingerprinted public assets. Keep personalized pages private/no-store as appropriate. Preserve cache-busting on releases. Managed builders own their delivery stack; use their native optimization controls.
Test the complete journey
Re-measure under comparable conditions, then submit a form or test checkout. Check signed-in versus signed-out views, currency/location variants and mobile layout. Track field data over time instead of expecting immediate changes to aggregated reports.
Implementation recipes
Expand · choose · copy</>A responsive first-screen imageOpen recipe
Custom HTML or an equivalent builder image control. Generate the actual image files first. Use descriptive alt text appropriate to the real image.
<picture>
<source type="image/avif"
srcset="/images/team-640.avif 640w, /images/team-1280.avif 1280w"
sizes="(max-width: 720px) 100vw, 60vw">
<img src="/images/team-1280.jpg"
width="1280" height="853"
fetchpriority="high"
alt="Describe the actual team and setting shown"
style="width:100%;height:auto">
</picture>
<!-- Use high priority for the actual important LCP image, not every image.
Use loading="lazy" for suitable below-the-fold images instead. --></>Separate public assets from private responsesOpen recipe
An Express backend you control. Requires Express and a fingerprinted assets build. Managed builders must use their own supported cache controls.
// Add to your existing Express app after your normal app initialization.
// Only content-hashed PUBLIC assets belong in this directory.
app.use("/assets", express.static("dist/assets", {
maxAge: "1y",
immutable: true,
fallthrough: false
}));
// Set headers before any personalized response is sent.
// Authentication is still required; no-store is not access control.
app.use("/account", (req, res, next) => {
res.setHeader("Cache-Control", "private, no-store");
next();
});
// Adapt for authenticated APIs, cart and checkout.
// Confirm your CDN does not override these headers.
// Do not apply the asset rule to HTML, personal data or unversioned files.Save comparable before/after runs and confirm no regression in forms, checkout, personalization or accessibility. Performance changes should solve an observed bottleneck.
Revert the template/cache change or previous deployment. Purge only affected cached content if necessary and recheck personalized routes.
Read the primary instructions
Guidance checked October 7, 2026. “2027” describes this prototype’s visual concept, not a prediction of platform rules.