When you open Lyrebird from the Bp toolbar, it runs in a small built-in browser window on your computer, and it has to share your computer's memory with Best Practice itself. Slow loading almost always comes down to one of those two things — a cache that has grown too large, or too little memory left for the window to open into.

You can stop as soon as things improve — most practices find the first one makes an immediate difference.

Still slow after all of those? Please get in touch — there's a short list of details that help us pick it up quickly.

This section is for you if Best Practice closes on its own, stops responding, or shows an error box like the one below while you're using Lyrebird.

Usually not — but check your Lyrebird History page before you do anything else. Completed consults save there automatically, and a consult that was interrupted partway through is often still there and can be rebuilt.

If the consult isn't in History at all and is still within your storage period, it may not have been saved. How to recover a lost or missing consult walks through this in full, including a short video. If you believe a consult should be there and isn't, contact us with the date and approximate time — please don't include the patient's name, as we don't need patient details to look into it.

Best Practice can only use a limited amount of your computer's memory, regardless of how much the computer has. Every open patient file uses part of that allowance, and the Lyrebird window needs its own share. As that limit is approached everything slows down — and if it's reached, the window can freeze or Best Practice can close altogether. It's the same underlying cause as slow loading, which is why the fixes overlap.

Best Practice support have identified a workflow that can also cause this, and are working on a fix. It looks like this:

If that matches what you were doing, please let us know.

Best Practice displays Lyrebird using a Microsoft component called WebView2 — the same component Best Practice uses for other pages inside the application, such as help links and the latest news panel. When you see a WebView error, it's this component that has run into trouble, not Lyrebird itself.

Some setups see this error return even after all of the above, particularly practices running Best Practice on terminal servers or virtual desktops. If that's you, please contact us rather than continuing to work around it — send us your Bp error log and the details listed here.

These are the fixes referred to in the sections above. If you've landed here directly, start with the section that matches what you're seeing — it will tell you which of these to try and in what order.

Like any browser, the Lyrebird window saves temporary files — a "cache" — so things load faster next time. Over months of use those files build up, and past a certain point they stop helping and start getting in the way. Clearing them gives Lyrebird a clean start.

This is the most common cause of slow loading and resolves it for most practices.

Some practices have the Inspect option disabled. If so, you can remove the files directly. This is also the method to use for a WebView error.

​

Deleting this folder is safe — it contains only temporary files, and Best Practice recreates it automatically.

Every patient file you leave open uses part of Best Practice's memory allowance, and Lyrebird needs some of it too. When lots of files are open at once there's little left over, so Lyrebird takes longer to open and can freeze.

The memory issue above doesn't fully clear when you close individual patient files — some of it accumulates across the whole session. Restarting Best Practice releases all of it at once and gives Lyrebird a clean environment to open into. It's also the quickest way to recover if things have already slowed down mid-clinic.

Best Practice and Lyrebird maintain a connection so that Lyrebird knows which patient you have open and can pull their details across. Occasionally that connection gets into an unhealthy state — usually after an update, a server restart, or a network interruption. Lyrebird keeps working, but spends longer than it should re-establishing the connection each time it opens.

Try this step if: Lyrebird is slow and patient details aren't pulling through properly, or the "L" button isn't behaving as expected.

You'll need Best Practice administrator access:

You may need your practice manager or IT provider to do this if you don't have administrator access. These steps also appear in the BP Integration FAQ.
​

If you need to do something in Best Practice partway through a consult — write a script, print a document — finish and close the consult in the Lyrebird window first, then carry on in Best Practice. Ending the consult from the Best Practice screen while Lyrebird is still running is a known trigger for crashes.
​

Some antivirus and endpoint protection tools interfere with WebView2, the component Best Practice uses to display Lyrebird. Your IT provider can test whether this is the cause by temporarily excluding Best Practice from scanning.
​

This is a task for your IT provider. Best Practice have published their own steps to troubleshoot this issue. Please don't attempt registry edits or permission changes yourself.
​

If several people at the practice are affected at the same time, the problem is more likely to sit with the server than with any individual computer. Ask your IT provider to restart the Best Practice server outside clinic hours.
​

If nothing above has helped, it's likely something in your practice's hardware or network setup. The single biggest factor is whether workstations are running a solid state drive (SSD) rather than a mechanical hard drive — Lyrebird reads and writes a large number of small temporary files each time it opens, which is exactly the workload mechanical drives handle least well.

Ask your IT provider to check your setup against Best Practice Software's recommended specifications.

Best Practice keeps its own error log, and sending it to us is the single most useful thing you can do for a crash or a persistent WebView error. It records what the software was doing at the moment things went wrong, which we can't see from our side. You can find it and send it yourself in about a minute, without waiting on your IT provider or Best Practice support.

Whichever of the three problems you're seeing, these details let us pick it up straight away:

A couple of extras depending on what you're seeing:

Please don't include patient names or other patient details — we don't need them to investigate, and the date and time are enough for us to find the right records.

Our support team is happy to help.