Performance Troubleshooting

Slow page loads

If pages take more than a few seconds to load, the issue is usually network-related or caused by stale cached assets.

CDN and caching:

• The platform serves static assets through a CDN. If you are far from the nearest edge node, initial loads may be slower. Subsequent loads should be fast due to caching.
• After a platform update, your browser may hold stale cached JavaScript bundles. Hard refresh with Ctrl+Shift+R (Windows/Linux) or Cmd+Shift+R (macOS) to force a fresh download.
• If hard refresh does not help, clear all cached data for ivybiosciences.com in your browser settings.

Network diagnostics:

1. Open DevTools (F12) and go to the Network tab.
2. Reload the page and look at the waterfall chart.
3. If most time is spent on "Waiting (TTFB)" for the HTML document, the issue is server-side or network latency. Check your connection to the nearest Vercel edge.
4. If time is spent downloading large JavaScript bundles, the issue is bandwidth. Check your connection speed with a speed test.
5. If many requests show (blocked) or (failed), an extension or firewall is interfering. Try incognito mode.
6. If DNS resolution is slow (visible in the waterfall as a long blue segment), your DNS resolver may be sluggish. Try switching to a faster DNS (1.1.1.1 or 8.8.8.8).

Specific slow pages:

• Job detail: Large result files (for example big docking outputs) take time to parse in the browser.
• Canvas: See the "Canvas rendering lag" section below.
• Projects with many jobs: A project with hundreds of jobs loads more slowly on the first visit. Archive jobs you no longer need.

Chat response latency

Chat responses stream from the AI model in real time. Perceived latency has several components.

Model selection and latency:

• Smaller models answer faster than the largest ones. If you don't need the most capable model, pick a faster one in the chat header's model selector. Faster models suit factual lookups, simple calculations and follow-up questions.

Thinking mode overhead:

• With thinking on, the model reasons before it writes visible output, with a budget of up to 5,000 tokens in "auto" mode and 8,000 when thinking is "on". That delays the first visible token.
• Set thinking to "off" for quick factual queries. Use "on" for thorough analysis, multi-step research plans, or complex tool orchestration.

Tool execution latency:

When the AI invokes tools (database lookups, job submissions), each tool call adds to the total response time. The chat shows a loading indicator for each active tool call.

Database lookups (UniProt, PubChem, NCBI, ChEMBL) usually take seconds. GPU tools (docking, folding) take minutes. Rough ranges per category are in the tool execution time reference below.

• If a tool call seems stuck, check the active tool cards in the chat. A spinning indicator means the tool is still running, not frozen.
• Tool timeouts are enforced server-side. If a tool exceeds its timeout, the AI receives an error and attempts an alternative approach or reports the failure.
• A response that calls several tools takes longer than one that calls a single tool. GPU jobs run asynchronously on Modal, so the answer can arrive before a long job finishes.

Streaming interruptions:

If the response stops mid-stream and then resumes after a pause, your network connection may be unstable. SSE (Server-Sent Events) connections are sensitive to network interruptions. See the Network troubleshooting page for details.

Canvas rendering lag

The canvas displays job results as interactive cards. Performance depends on how many cards are loaded and their complexity.

Reducing canvas lag:

• Keep cards at Tier 1 (the preview) unless you're reading them. A Tier 1 card doesn't mount its renderer, so it uses no WebGL context.
• Keep only a few 3D viewers open at once. Each one holds its own WebGL context, and browsers cap the number of contexts per page.
• If the canvas is unresponsive, remove cards for finished work: select them and press Delete or Backspace.
• See Canvas issues for more.

WebGL issues:

• 3D viewers need WebGL. If your browser or GPU drivers don't support it, the viewer shows a blank area.
• Check WebGL support by visiting chrome://gpu (Chrome) or about:support (Firefox) and looking for WebGL in the features list.
• Integrated GPUs work but are slower than discrete GPUs on large structures.
• If you are on a laptop, ensure it is using the discrete GPU (if available) rather than the integrated one. Check your OS graphics settings.

Large result sets

Some tools return thousands of results (compound screening, similarity search, batch ADMET).

• Pagination. Large result tables are paginated. Larger page sizes render more slowly.
• Filtering. Narrow results with the table's filters (score threshold, property ranges) before browsing.
• Downloading. To work with the full result set, download the job's outputs (ivybloom jobs download JOB_ID) rather than scrolling through the UI.
• Sorting. Sorting a very large table can freeze the tab briefly while the browser re-renders.

Memory usage

The platform is a data-intensive application. Browser memory usage can be significant, especially with 3D viewers and large datasets.

Memory-intensive features:

• 3D viewers: Each viewer's memory grows with structure size, so a large complex uses far more than a small ligand.
• Canvas with many cards: Every card with a mounted renderer holds memory.
• Chat with long history: A chat with hundreds of messages and embedded results accumulates memory. Starting a fresh chat reclaims it.
• Multiple browser tabs: Each platform tab runs independently, so their memory adds up.

Reducing memory usage:

1. Close browser tabs you are not using. Each platform tab maintains its own memory allocation.
2. Switch canvas cards back to Tier 1, or remove cards for completed work.
3. Start a new chat session if the current one has a very long history.
4. Use Chrome's Task Manager (Shift+Esc) to identify which tabs are using the most memory.
5. If using Firefox, visit about:memory for detailed memory reports.

Tool execution time reference

For planning your workflow, here are typical execution times by tool category.

These are rough ranges with a warm worker; input size moves them a lot. A cold start adds the time Modal needs to start a container.

Self-hosting performance

If you are self-hosting the platform, additional factors affect performance.

• Database location. Ensure your Supabase instance is in the same region as your Next.js deployment. Cross-region queries add 50-200ms per request.
• Redis. Redis backs rate limiting and caching. Without it, rate limits fall back to per-instance memory and more requests reach the database. Check that Redis is running and reachable.
• Node.js memory. npm run dev starts Next.js with a 6 GB heap, and npm run build with 16 GB (override it with NEXT_BUILD_HEAP_MB). If the production server crashes on memory, raise NODE_OPTIONS="--max-old-space-size=…".

Keyboard shortcuts for faster navigation

Using keyboard shortcuts reduces the time spent on navigation and repetitive actions.

Canvas shortcuts are listed in Canvas issues.

Browser-specific performance notes

• Chrome generally offers the best performance for the platform, particularly for WebGL rendering and large DOM trees.
• Firefox works fully. Its about:memory page shows where a tab's memory goes.
• Safari is energy-efficient on macOS, but Mol* viewers run noticeably slower than in Chrome.
• Edge uses the same engine as Chrome and performs about the same.

Collecting diagnostics

If performance issues persist after trying the above:

1. Open DevTools and go to the Network tab. Reproduce the issue, then right-click the request list and select "Save all as HAR."
2. Open the Performance tab, click Record, reproduce the issue, then stop. Take a screenshot of the flame chart.
3. Note your browser version, OS, and approximate RAM/GPU.
4. Record the page URL, timestamps, and any visible error messages.
5. Submit a support ticket with these files and notes.