WeWeb Performance: Lighthouse Scores, Load Times, and Optimization

Before optimizing, establish your baseline. Open your published WeWeb app URL in Chrome (not the editor preview). Open Chrome DevTools (F12 or Cmd+Option+I) → click the Lighthouse tab → select Mobile category (this is harder to score and more representative of real users) → click Analyze page load. Wait 30-60 seconds for the report. Record your scores for: Performance (most important — target 70+), First Contentful Paint (FCP), Largest Contentful Paint (LCP), Total Blocking Time (TBT), and Cumulative Layout Shift (CLS). Screenshot the report. Also note the Opportunities and Diagnostics sections — these show specific items causing poor scores. Run Lighthouse 3 times and average the scores, as single runs can vary by 10-15 points due to network conditions.

Large DOM trees are a primary cause of poor WeWeb Lighthouse scores. Every element on a page — visible or hidden via display:none — adds to the DOM and increases memory usage, style recalculation time, and layout time. Lighthouse flags pages with more than 800 DOM nodes as problematic. Audit your project: for each page, identify large sections that only some users will see (admin panels, premium content, expanded detail views, alternative UI states). Convert their visibility from CSS display binding to Conditional Rendering. Conditional Rendering uses Vue's v-if under the hood — elements do not exist in the DOM at all when the condition is false. In the editor: select the section → Settings tab (right panel) → Conditional Rendering → bind to the appropriate condition. Focus on the biggest sections first: a hidden admin panel with 50 elements has more impact than a single hidden button.

By default, WeWeb collections configured on a page fetch their data when the page loads — even if the data is not immediately visible to the user. On pages with multiple collections, this creates parallel network requests at page load that compete with rendering. Audit your page's collections: Data panel → Collections → look at each collection's fetch mode. For collections that are only needed when a user takes an action (clicking a tab, opening a modal, expanding a section), change their fetch mode to 'On demand' — they will only fetch when explicitly triggered by a workflow action. For collections that contain large datasets, enable pagination (limit to 20-50 items per page). For collections used across many pages, consider 'Cached' mode — WeWeb caches the response and avoids re-fetching on every page navigation.

WeWeb's DataGrid component is built on AG Grid and supports virtual scrolling — a technique where only the rows currently visible in the viewport are rendered in the DOM, not all rows. Without virtual scrolling, a DataGrid with 1,000 rows renders 1,000 DOM rows, causing severe performance issues. To enable virtual scrolling: select your DataGrid element → open the Settings tab (right panel) → find the Row Virtualization setting → enable it. Also configure Row Height to a fixed pixel value (required for virtual scrolling to calculate row positions). With virtual scrolling enabled, a 10,000-row DataGrid renders only ~30 rows in the DOM at any given time, regardless of total row count. For data that is not in a DataGrid (e.g., a repeating container with hundreds of items), implement server-side pagination using collection pagination settings to limit items fetched.

1// Supabase SQL — server-side pagination for collections
2// Use with WeWeb collection offset/limit parameters
3// In Supabase Dashboard → SQL Editor (NOT in WeWeb)
4
5-- Example: paginated products query with filtering
6SELECT 
7  id,
8  name,
9  price,
10  category,
11  created_at
12FROM products
13WHERE 
14  ($1::text IS NULL OR category = $1)  -- filter param
15  AND is_active = true
16ORDER BY created_at DESC
17LIMIT $2  -- page size param
18OFFSET $3;  -- offset param = (page - 1) * page_size
19
20-- Count query for pagination UI
21SELECT COUNT(*) as total
22FROM products
23WHERE 
24  ($1::text IS NULL OR category = $1)
25  AND is_active = true;

Images are typically the largest assets on any web page and a major contributor to slow LCP (Largest Contentful Paint) scores. For images in WeWeb: first, convert all JPG and PNG images to WebP format before uploading — WebP is 25-35% smaller than JPG at equivalent quality. Use Squoosh (squoosh.app) or ImageOptim to convert and compress. When uploading images to WeWeb, verify you are uploading WebP files. For images in repeating containers (product cards, user avatars, content lists), enable lazy loading: select the Image element → Settings tab → find the Loading property → set to 'lazy'. Lazy loading defers image loading until the image is about to scroll into view. For hero images and above-the-fold content that affects LCP, do NOT lazy load them — they should load immediately. Also ensure images have explicit width and height attributes set to prevent layout shifts (CLS).

WeWeb's workflow system executes JavaScript at runtime. Heavy workflows that run on page load, complex formula evaluations that run on every render, and large custom JavaScript actions all contribute to Total Blocking Time (TBT). To reduce JavaScript execution: audit your 'On page load' and 'On app load' workflows — these run before the page renders and block the main thread. Move any workflows that are not needed for initial rendering to 'On mounted' (runs after initial render) or to on-demand triggers. Review custom JavaScript actions for expensive operations: sorting large arrays, complex string manipulations, or deeply nested loops. Consider moving heavy computations to your backend (Supabase Edge Function or Xano) and fetching the pre-computed result instead. Also audit the NPM packages installed via the NPM plugin — each package adds to your JavaScript bundle. Remove packages you no longer use.

WeWeb Cloud hosts on AWS infrastructure, which performs well in US and European regions but can be slower for users in Asia, South America, or Africa. Cloudflare Pages distributes your static files across 300+ edge locations globally, meaning users in any region get files served from a nearby server. To measure the difference: use WebPageTest (webpagetest.org) to run tests from multiple geographic locations against both your WeWeb Cloud URL and a Cloudflare Pages URL. To self-host on Cloudflare: set up GitHub sync in App Settings → Git Integration → connect your GitHub repo. In Cloudflare dashboard → Pages → Create a project → Connect to Git → select your WeWeb repository. Set the build command to empty (WeWeb pre-builds), output directory to / (root). Deploy. For apps with significant international user bases, self-hosting on Cloudflare Pages typically reduces Time to First Byte by 50-80% for non-US/EU users compared to WeWeb Cloud.

WeWeb apps are single-page applications with no server-side rendering (SSR). This means when Google's crawler or social media scrapers (Facebook, Twitter, LinkedIn) request your page, they receive an empty HTML shell with a JavaScript file — not pre-rendered content. Google can index JavaScript-rendered content but with delays of days to weeks. Social media OG tags (for link previews) are particularly affected — scrapers often do not execute JavaScript. Prerender.io solves this by pre-rendering your pages to static HTML on a schedule and serving that HTML to bots while serving the SPA to real users. Integration: set up Prerender.io → configure your CDN (Cloudflare, Vercel, or Netlify) to detect bot User-Agents and route them to Prerender.io instead of your SPA. This is the recommended approach for any WeWeb app that needs search engine visibility.

1// Cloudflare Worker — route bots to Prerender.io
2// Deploy via Cloudflare Workers dashboard
3// This worker intercepts bot requests and returns pre-rendered HTML
4
5async function handleRequest(request) {
6  const url = new URL(request.url);
7  const userAgent = request.headers.get('User-Agent') || '';
8  
9  const botPatterns = [
10    'Googlebot', 'bingbot', 'Slurp', 'DuckDuckBot', 'Baiduspider',
11    'YandexBot', 'facebookexternalhit', 'Twitterbot', 'LinkedInBot',
12    'WhatsApp', 'Slackbot', 'TelegramBot'
13  ];
14  
15  const isBot = botPatterns.some(bot => 
16    userAgent.toLowerCase().includes(bot.toLowerCase())
17  );
18  
19  if (isBot) {
20    const prerenderUrl = `https://service.prerender.io/${url.toString()}`;
21    return fetch(prerenderUrl, {
22      headers: {
23        'X-Prerender-Token': 'YOUR_PRERENDER_TOKEN',
24        'User-Agent': userAgent
25      }
26    });
27  }
28  
29  return fetch(request);
30}
31
32addEventListener('fetch', event => {
33  event.respondWith(handleRequest(event.request));
34});