How to make snaps faster

by Igor Ljubuncic on 8 October 2021

A great user experience is (or at least, should be) an integral part of any software that involves user interaction. On the desktop, this starts with the application launch, and continues through the session. The overall time to completion of tasks as well as interactive responsiveness are a core element in this journey.

If you’re a snap developer or publisher, the topic of speed may arise for various reasons. The differences in the overall architecture and principles of operation of snaps, in comparison to software deployed as Deb or RPM packages, can sometimes lead to a slower experience. This goes against the prime directive of desktop usage. In this article, we want to show you a number of methods and tools you can use to make your snaps snappy.

Compression method

As we’ve outlined in the LZO compression adoption announcement last year, the most immediate change that developers can implement is the use of the LZO compression for their snaps. You may also want to check the more detailed follow-up article explaining why this particular compression algorithm was chosen for snaps.

This will result in some increase in the snap size, but it will typically lead to 2-3x improvement in snap startup times. To implement LZO, you need to declare a top-level compression keyword in your snapcraft.yaml file:

compression: lzo

Desktop extensions

Snapcraft extensions are collections of reusable components and declarations that publishers can add to their snapcraft.yaml. These extensions can reduce the size of the snap recipe, as well make snap builds simpler and more consistent. Instead of manually declaring various plugs, build and stage libraries, and environment variables, developers can use an extension, like GNOME or KDE neon, and hide away large chunks of code

adopt-info: kblocks
        - kde-neon
        common-id: org.kde.kblocks.desktop

Snapcraft extensions have other advantages. They reduce the need for in-depth knowledge of the target software stack, offer a common template, and improve security, as they are tested and updated independently.

When it comes to speed, the benefits come in two ways:

  • Firstly, Snapcraft extensions can make snap smaller – and thus faster to launch. Among the different magic methods that abstractize code, the extensions declare the use of various content snaps, including runtime libraries, themes, icons, and other assets. Normally, these would have to be decompressed and loaded into memory during the first application runtime (for each snap), which can lead to a time penalty. Any application that relies on common content snaps that have already been loaded into memory will benefit from faster access times. For example, the following definitions are automatically added by the extension:
    default-provider: gnome-3-38-2004
    interface: content
    target: $SNAP/gnome-platform
    default-provider: gtk-common-themes
    interface: content
    target: $SNAP/data-dir/themes
    default-provider: gtk-common-themes
    interface: content
    target: $SNAP/data-dir/icons
    default-provider: gtk-common-themes
    interface: content
    target: $SNAP/data-dir/sounds
  • Secondly, the extensions introduce commonality, leading to fewer duplicates or unnecessary content inside snaps. If you manually package snaps, you could add potentially incompatible libraries, duplicates, or unneeded assets, which may complicate the startup sequence and consume more resources. With the extensions, this problem is minimized.

Get your own measurements in…

It is also always useful to try to profile your own snap, to get a good understanding of what it does and how it behaves. You can use a multi-purpose tool like etrace, which is designed to work with snaps, and allows detailed analysis of the startup sequence in a precise way. For instance, the Chromium snap is a great example of a snap that benefited massively from the use of the extensions, both in terms of speed and size.

Other methods

Even if, for some reason, you cannot use the extensions in your workflow, you can adopt some of the ideas and practices embedded in them in your snapcraft.yaml. You can use the content snaps where applicable.

  • Remove any unnecessary stage packages.
  • Do not include development packages (-dev) in the stage packages section, as these are most likely used in the build step, and not required for runtime.
  • Use the prime keyword declaration to exclude any files you do not need in the final artifact (the snap). You can include or exclude files (with the minus (-) sign added). For example, to not add the include and pkgconfig subfolders that may be part of your sources used in the build step of the snap, you could use a declaration like below:
  - -usr/include
  - -usr/lib/pkgconfig


The speed and responsiveness of applications contribute greatly to the user experience. With snaps, there could be some differences in typical execution times compared to applications packed the traditional Linux way. However, it is possible to narrow, and even eliminate the gap. The use of the LZO compression and Snapcraft extensions, and the cleanup of unnecessary assets can help make the snaps smaller, tidier and faster to start. If you have any questions or ideas around this topic, please join our forum and let us know what you think.

Photo by Joe Neric on Unsplash.

Newsletter Signup

Related posts

Managing software in complex network environments: the Snap Store Proxy

As enterprises grapple with the evolving landscape of security threats, the need to safeguard internal networks from the broader internet is increasingly important. In environments with restricted internet access, it can be difficult to manage software updates in an easy, reliable way. When managing devices in the field, change management […]

Creating Snaps on Ubuntu Touch

This article was written in collaboration with Alfred E. Neumayer of the UBports Project. Tablets, phones and current technology’s capabilities are phenomenal. Who would have thought a thin, light, barely 10 inch device would provide all the power necessary to run Virtual Machines, wherever one desires while powered on battery? That a sma […]

We wish you RISC-V holidays!

There are three types of computer users: the end user, the system administrator, and the involuntary system administrator. As it happens, everyone has found themselves in the last group at some point or another; you sit down to perform a task relevant to your needs or duties, but suddenly the machine does not work as […]