How we continuously improve the performance of Linchpin

A few weeks ago, Linchpin Intranet Suite 5.1 and Linchpin Essentials 2.1 emerged! Guided by customer feedback, our focus was on "performance and stability," since Linchpin instances are becoming larger and more heavily used. These releases are exciting because performance is a very important topic for us (and a rather complex one, but more on that later). In this article, we'll show how Linchpin was optimized and what our general stance is on the topic of "performance".

Why performance should not be neglected

New features are great, no question. We like to build them, you like to use them. But, maybe not always. Let’s be honest, after a certain point, every new feature probably won't be used by every user - especially in companies that have a very large and diverse workforce. Performance, on the other hand, is a topic whose optimization really benefits all users. Whether it's IT, marketing, or sales departments, corporate communications, or just readers - if you interact with the system, you're affected.

In addition, improvements in performance bring real added value. Especially in daily work, this should not be underestimated. For instance, it could be the few seconds it takes to load content on your computer. Of course this might not seem like much, but these seconds add up very quickly over the course of an 8-hour workday. Typically, we end up opening more than just 2-3 pages per workday. If we can reduce loading times, we ensure less time is wasted, consequently productivity increases, and above all, less frustration for users who just wanted to look something up quickly. So the cost-benefit calculation works out. You could even say that improvements in performance bring users more actual benefits than constantly adding new features.

Performance optimizations for News

That's why Linchpin Intranet Suite 5.1 brings performance improvements for News. The biggest change is that we only load data that is really necessary for a page or specific element to function. In the news hub, magazine and onboarding, these changes have allowed us to reduce the size of elements that need to be loaded. In addition, we introduced a new library for the date in a news item, which reduces the quantity of data needed to be loaded as well.

Disclaimer: All following values refer to tests in our test environment.

The Corporate News Feed and Personal News Feed macros also get performance boosts. We were able to significantly reduce the amount of data loaded and the loading times. 

User profiles with improved performance

The performance improvements affect the user profiles in such a way that we were able to significantly reduce the loading times for pages with many macros. For the Custom User List and Custom User Search macros, only data configured for display is loaded.

Several customer reports described cases where there were many "profile" macros used on a single page, which led to quite long loading times. For Linchpin Intranet Suite 5.1 and Linchpin Essentials 2.1, we were able to greatly improve the performance of such pages.

Content is now reloaded in the frontend instead of the backend, and caching has also changed. This means that the basic structure of a page with many "profile" macros should now load much faster. The loading time for the entire page is consequently reduced as well.

Why performance is a complex issue

Improving performance in a meaningful way is not always easy. This is mainly because we don't know what the systems "out there" look like. We don't know how many users access pages at the same time, how many macros and data are stored on our customers' pages. Depending on the size of the system, the amount of data and also the technical solutions used (for example, the type of database), Linchpin's performance may vary. In addition, third-party apps can also have an impact on pages. There are so many apps, and we may not have even noticed some of them during our tests.

Orientation to customer use cases

As already mentioned, we don't know how many systems are used. This means that our tests are often carried out under laboratory conditions. This is precisely why customer reports on performance issues are extremely important and useful to learn about the actual use cases of our customers and, above all, to recreate them. This allows us to test more specifically and see whether our software really does not run as fast as it could in such cases. Of course, we also incorporate the findings into the rest of our apps, so that they also benefit from the performance improvements. 

Are you currently experiencing performance-related problems? Are things not loading as fast as they should or as you would expect? Please contact us at and we'll take a look at it! Please remember: The more detailed your ticket is, the better we can work on the issue. 

However, we are not just sitting around waiting for your reports. We also conduct our own analyses, looking for indicators of possible bottlenecks within Linchpin. In fact, we've had a dedicated performance task force for exactly this purpose for some time. Again, if we find something we can improve, we carry that knowledge into the rest of our apps.

Possible causes of performance problems

The error analysis itself is usually much more time-consuming than the solution to the problem. One of the reasons for this is that the issue of performance is present at virtually all levels of development, so there can be many possible trouble spots. For example, a browser can be a bottleneck, since most browsers behave differently. The browser you use can have an impact on the performance of a system.

It's also important to look at how our resources are loaded. Linchpin also stands for interactive content and where there is interactivity, there is JavaScript. So if (many) elements are added afterwards, it can also have an impact on the performance of a page. Of course, the same applies to the amount of data that is sent from the server. The more data there is, the slower the processing/reading could be. So it drags on, down to the database level, where, for example, the number of times a database is accessed can affect performance.

Further Reading