Optimizing page load speeds on SvelteKit

SvelteKit is a popular frontend framework for web development based on the Svelte component model. In this developer post, we share useful tips on how to optimize page load speeds for SvelteKit websites.

About Trading Strategy

Trading Strategy is a new service for algorithmic and technical trading of cryptocurrencies on decentralised exchanges (DEXes).

Algorithmic trading is a derivative of technical analysis; taking trading positions based on pure mathematics and data. Algorithmic trading is part of quantitative finance, the opposite of value investing where trading decisions are made based on fundamentals. Algorithmic trading provides a systematic approach to trading compared to methods based on trader intuition or instinct. Whereas technical analysis often aids humans to take trading positions, in its purest form in algorithmic trading a trading program follows a set of trading rules and independently executes trades on the market 24/7.

Read our earlier blog post on our software architecture.

Why the page load speed matters

Browsable web can be roughly divided into two use cases: public information pages and private applications. Public pages include news sites, e-commerce, information portals, public social media (Twitter) and such. Private applications require login to access any information and are usually either business services (online bank, private social media like Facebook) or corporate portals (intranet). For the public browsable web, there is a concept of long-tail traffic and new visitors: how much eyeballs find your website, usually through search engines and social media sharing.

For the pristine eyeballs

  • How fast the website loads is the most important factor, otherwise short attention span audience starts to drop off
  • Search engines like Google have started to use page load speed as the ranking indicator, as they know directing the audience to the faster websites give them more pleasurable results. Thus, especially if you are selling something, it is important that your page loads fast, as then it will rank above your competitors in the search results.

For pristine eyeballs, only the cold page load with all caches empty, as that is also how the new visitor experience your website.

The page load speed can be measured with a few metrics

  • Time to first byte: How quickly a web browser receives the HTML payload from the server. This consists of TLS handshake to establish HTTP connection, initial server response time how fast the server generates the reply (SQL query delays and such) and then actual link latency (the light travels around the globe in ~150 ms). Link latency is also affected by the speed of the Internet: with low bandwidth, 3G connection websites naturally load slower.
  • First contentful paint (FCP): How fast the user perceives something on a web browser window instead of a blank white screen. This may include decoding HTML, loading CSS, loading JavaScript and/or executing JavaScript.
  • Largest contentful paint  (LCP): How long it takes to receive the largest paint on the page e.g. in the case there are skeleton placeholders, how fast these are filled. LCP may also cause fonts to become loaded and then it retriggers the page layout shifts with different font size metrics. Another sad cause of LCP events is any pop-up, like a cookie disclaimer or a permission pop-up asking you to be tracked.
  • Time to interactive: When the page can respond to user interaction like pressing a button.

Good rules of thumbs values are 1.5 seconds for FCP and 2.5 seconds for LCP. Basically, your website should be user-readable under 1.5 seconds after a user clicks a link.

Measuring your website load speed

Here are some tools to measure your page speed, in the order of importance.

Chrome Performance panel

Chrome Performance panel in web developer tools is the most important tool. It allows you to simulate different speed test scenarios locally, over a simulated link latency.

  1. Open your localhost with Performance panel open
  2. Caches should be disabled when the performance panel is open
  3. Hit the record button - this will reload the page and keep loading until everything is loaded
  4. Turn connection simulation to "Slow 3G"
  5. The performance panel will show you a timeline of loading different items, plus FCP, LCP and other metrics

PageSpeed Insights

PageSpeed Insights is important as Google is internally using the same, or similar, service to rank your site speed in the search results.

Give any website URL and PageSpeed gives a report for mobile and desktop use cases.


WebPageTest is similar to PageSpeed Insight, but more focused on waterfall view of different resources loaded. You can get the same output from the Chrome Performance panel. You can easily test different geographic locations and web browser versions.

Some measurements, like TLS handshake delay, are more carefully broken down.

Bringing down the page loading times in SvelteKit

Server-side rendering

The most important optimisation is actually built-in to SvelteKit: server-side rendering (SSR). Instead of sending skeleton web pages to a browser from a server, we send the actual rendered complete HTML pages.

SvelteKit is the most developer-friendly frontend framework that comes to SSR. SvelteKit makes building hybrid applications, where the first page is rendered server-side, but the subsequent page loads, or routes, are rendered client side.

For reference, you can read our SSR configuration using the Node.js adapter. We run a CloudFlare -> Caddy -> Node.js adapter pipe.

Content-delivery network

We use CloudFlare as CDN. Cloudflare acts as a reverse proxy for your website. Any static media resources (CSS, JS, images) are cached at the Cloudflare edge serves all around the world. This will make any cacheable assets load very fast because the browser of the user fetches these resources over low link latency, local, edge server instead of roundtripping around the world.

Enabling Cloudflare with SvelteKit is no-op operation: required caching headers and cache invalidations are built into the SvelteKit.

Optimizing CSS bundles

CSS loading is a blocking operation in web browsers. The first contentful paint cannot happen until all CSS files from <head> are loaded.

We did two tricks here

  • We hand-tuned our Bootstrap CSS bundle by removing components we do not need. We commented out those in the theme and recompiled the theme. We also reduced some extra styles, like colour and size variations, generated by the stock theme.
  • Disable manual chunks in Vite configuration. We do not have what this does, as we could not find high-quality documentation on the topic, but it got rid of a lot of early CSS loading.

Removing fonts for mobile

We have two fonts: Open Sans and Exo 2. The font data is 40% of the download payload size. We simply do not load fonts for mobile phones, using this CSS trick. This brings our mobile PageSpeed score up a lot. Naturally, the page looks uglier for mobile users. We feel this is a trade-off: our users are here for content, not for beautiful typography.

Note that we rather not load fonts on slow connections, not on mobile screens, but as far as we know there is no way to filter assets based on the link speed connection.

Self-host fonts

Today, there is no longer a benefit to using Google CDN, or any other non-primary domain CDN, for fonts delivery because of the web browser cache isolation.

We moved fonts to self-hosting from Google Fonts using this google-webfont-helper.

Enable externalFetch hook

For server-side page rendering, our Node.js SSR process can directly connect to our backend using the externalFetch hook of SvelteKit. Any SSR'ed backend API request can travel in the private network, instead of roundtripping through the public network, causing extra latency.

See our externalFetch hook.

HTTP 103 Early Hints

This optimization is not yet supported in production web browsers. When the support lands we will write a separate blog post on the topic. However, you can see our HTTP 103 Early Hints code in SvelteKit hooks already.

Trading Strategy is an algorithmic trading protocol for decentralised markets, enabling automated trading on decentralised exchanges (DEXs). Learn more about algorithmic trading here.

Join our community of traders and developers on Discord.

We are hiring

We are currently hiring for frontend (Svelte), backend (Python/PostgreSQL) and quant research (Jupytere Notebook/Pandas) positions. If you are interested in working with cryptocurrencies and algorithmic trading please email us at: [email protected].