Testing the Performance of Speckle Connectors
Today’s post is a bit different from what I usually publish. Normally, I dive deep into topics, break everything down with charts and tables, compare approaches, and highlight all the details that tend to stay behind the scenes. This time, I decided to take another route.
We’re talking about Speckle, and more specifically, about the Speckle Connectors for Revit, Navisworks, and IFC. Why these formats? The answer is simple – I use them every day, and I know exactly how they behave in real project conditions.
We’re talking about Speckle, and more specifically, about the Speckle Connectors for Revit, Navisworks, and IFC. Why these formats? The answer is simple – I use them every day, and I know exactly how they behave in real project conditions.
A little while ago on LinkedIn, I mentioned that I was planning a large-scale test for Speckle. The deeper I went, the clearer it became that this topic can’t fit into “just one post”. Speckle isn’t just a tool, it’s essentially an ecosystem. So I chose to start where anyone would start – with the connectors, because they are the entry point for exporting your model.
You won’t see any charts in this article. The reason is straightforward: charts are boring, and the number of tests I ran turned out to be too large. To eliminate randomness, I repeated each scenario three times. Here’s what the final testing setup looked like:
In total, that’s 54 exports within the main series alone. With additional checks included, the dataset expanded to over 200 measurements. Going through endless tables is not enjoyable, so I created a compact, interactive widget that presents the results more conveniently.
You won’t see any charts in this article. The reason is straightforward: charts are boring, and the number of tests I ran turned out to be too large. To eliminate randomness, I repeated each scenario three times. Here’s what the final testing setup looked like:
- 3 file formats
- 2 devices with different performance levels
- 3 runs for every test
In total, that’s 54 exports within the main series alone. With additional checks included, the dataset expanded to over 200 measurements. Going through endless tables is not enjoyable, so I created a compact, interactive widget that presents the results more conveniently.
Now, let’s move on to the results. Below is the widget I built based on all the collected data.
My plan is simple: as new test results come in, I’ll keep updating it, so you’ll always have access to the most up-to-date export performance statistics.
My plan is simple: as new test results come in, I’ll keep updating it, so you’ll always have access to the most up-to-date export performance statistics.
I used the same model I’ve shown before – a full, complex project that includes architecture, structure, and MEP. To avoid inconsistencies, I prepared three variations of it: a light, a medium, and a heavy version, each differing in file size and element count.
(To be honest, the model itself loads slowly, and I’m currently testing the Speckle Viewer as well — that will be a separate post.)
(To be honest, the model itself loads slowly, and I’m currently testing the Speckle Viewer as well — that will be a separate post.)
A quick note about the connector version.
For this round of testing, I used Speckle Connector 3.10. And, of course, right as I was finishing the measurements, version 3.11 came out. The developers are moving faster than I can dig into the details — which, honestly, is a good problem to have.
I’ll run the new connector through the same tests later and update the widget so you always have an accurate, up-to-date overview.
For context: all tests were performed in Autodesk Revit 2026 and Navisworks 2025, both fully updated. The IFC exports were done directly, without any intermediate workarounds.
For this round of testing, I used Speckle Connector 3.10. And, of course, right as I was finishing the measurements, version 3.11 came out. The developers are moving faster than I can dig into the details — which, honestly, is a good problem to have.
I’ll run the new connector through the same tests later and update the widget so you always have an accurate, up-to-date overview.
For context: all tests were performed in Autodesk Revit 2026 and Navisworks 2025, both fully updated. The IFC exports were done directly, without any intermediate workarounds.
Test Summary:
The testing showed that the speed and stability of exporting BIM models to Speckle are influenced primarily by two factors: the file format and the network speed.
Hardware performance does matter, but not as much as you might expect.
Hardware performance does matter, but not as much as you might expect.
Formats
RVT is the fastest overall.
The Revit Connector 3.10 sends repeated geometry only once, which helps native RVT models upload quicker and use less bandwidth. And since I was specifically testing first-time uploads, Revit also showed the fastest serialization stage.
NWC looks light on file size, but heavy on structure.
Navisworks splits models into thousands of individual objects. As a result, the file itself may be small, but the export process ends up being noticeably slower.
IFC performs well thanks to cloud processing.
Large files in the 300–800 MB range are handled server-side, which offloads processing from your machine and keeps upload times predictable. The drawback of IFC is described below.
The Revit Connector 3.10 sends repeated geometry only once, which helps native RVT models upload quicker and use less bandwidth. And since I was specifically testing first-time uploads, Revit also showed the fastest serialization stage.
NWC looks light on file size, but heavy on structure.
Navisworks splits models into thousands of individual objects. As a result, the file itself may be small, but the export process ends up being noticeably slower.
IFC performs well thanks to cloud processing.
Large files in the 300–800 MB range are handled server-side, which offloads processing from your machine and keeps upload times predictable. The drawback of IFC is described below.
Devices
A desktop PC with a wired connection delivers the best results.
High throughput (100–180 Mbps — it could have been higher, but the models finished uploading before reaching the limit) dramatically reduces export time.
A laptop on 4G falls behind by an order of magnitude.
For light models, this isn’t very noticeable, but with heavier ones, the gap becomes critical — up to a 15x difference. Cloud processing (the IFC uploader) performs best when the local machine is weak or the connection is unstable.
High throughput (100–180 Mbps — it could have been higher, but the models finished uploading before reaching the limit) dramatically reduces export time.
A laptop on 4G falls behind by an order of magnitude.
For light models, this isn’t very noticeable, but with heavier ones, the gap becomes critical — up to a 15x difference. Cloud processing (the IFC uploader) performs best when the local machine is weak or the connection is unstable.
A few interesting observations:
An NWC model can weigh only 3–20 MB yet contain 12–50k elements, which makes the export time grow much faster than with RVT, despite the small file size.
Large RVT models pushed RAM usage up to 14 GB. Laptops with 16 GB were already at their limit and started using the page file.
For the first time, I recorded upload spikes of 100 Mbps and higher on the PC, which noticeably accelerated the export process.
Large RVT models pushed RAM usage up to 14 GB. Laptops with 16 GB were already at their limit and started using the page file.
For the first time, I recorded upload spikes of 100 Mbps and higher on the PC, which noticeably accelerated the export process.
Practical takeaways
- If possible, export RVT directly.
- For heavy models or weaker devices, use IFC via the cloud uploader.
- Use NWC only when it’s genuinely required by your workflow.
- Always switch to a wired connection when exporting large models.
- Update the connector to version 3.10+ — it includes important performance optimizations.
Why I still don’t recommend using IFC for exporting to Speckle
Even though the IFC cloud uploader delivers predictable results and offloads processing from the local machine, I still wouldn’t consider IFC a primary format for exporting models to Speckle.
- IFC is not a native format. It’s already an export from another application. Any conversion adds time, complexity, and the risk of losing part of the data.
- Exporting IFC from Revit, Archicad, Tekla, or any other authoring tool takes noticeably longer. Whatever time you “save” on Speckle’s server-side processing, you lose during the initial IFC export.
- Additional load and resource consumption. Generating IFC is a heavy operation: it stresses the CPU, consumes a lot of RAM, and can even freeze the interface. With large models, this becomes a separate workflow stage on its own.
- Data structure isn’t always preserved. IFC often simplifies or transforms geometry. Some elements appear as extra, some native parameters disappear, and the resulting structure doesn’t always match the source model.
That’s why, even though Speckle handles IFC quite well through the cloud, I would still treat this format only as a fallback option, to be used when:
- your local machine is too weak,
- the model is extremely large,
- you need to offload as much processing from the PC as possible.
In all other cases, exporting RVT makes far more sense, while NWC should be used only when coordination requirements make it necessary.
I’ll continue running new tests and periodically updating the widget so the data stays current.
Overall, the results clearly show that native formats outperform converted ones, network bandwidth plays a major role, and Speckle’s ecosystem keeps evolving fast enough that it’s worth revisiting these benchmarks regularly.
Overall, the results clearly show that native formats outperform converted ones, network bandwidth plays a major role, and Speckle’s ecosystem keeps evolving fast enough that it’s worth revisiting these benchmarks regularly.