"i only speak liquid" #94: What PageSpeed actually cares about

Hey everyone,

Brandon is a talented developer based in Canada. His specialty is in geeking out on the many customisations available via Shopify. When he’s not deep in code, Brandon’s usually solving bouldering problems.

He’s an expert on Storetasker 😉 (apply here) and you can stay in touch with him here.

Let’s dive in 🤿

—

But wait before we do: I want to give a shout out to our partners at Hookdeck. Their team has built a tool for Shopify developers like y’all. Here’s what it’s all about:

Losing webhooks? Reclaim your sanity with Hookdeck 

Webhook issues led to customer complaints. Don’t let the next flash sale or bulk operation from your biggest merchant take down your app. Sound familiar?

Hookdeck Event Gateway acts as a middleware between Shopify webhooks and your app. It automatically queues webhooks, managing spikes and warning you of issues.

With a persistent event log, you can inspect, retry, and debug any webhooks.

Best of all, no code changes or background jobs required; just update your webhook URLs to get up to 10k free events per month.

Start for free 💯

What I’ve been thinking about:

What I’ve been thinking about ( shopify dev related, feel free to add code snippets)...

If you’ve ever opened Google PageSpeed Insights on a Shopify store and seen a low score, there’s a good chance a slider was blamed.

Most of the time, it’s not the slider itself but rather how the slider was built.

The biggest performance issues I see with sliders aren’t about animations or transitions. IT’S usually come down to too much JavaScript, issues with layout shift, or too much happening before the page is actually visible.

What PageSpeed actually cares about

Before talking libraries, it’s worth grounding this in what PageSpeed is measuring:

1. LCP (Largest Contentful Paint): How quickly the main content appears.

2. CLS (Cumulative Layout Shift): Whether elements jump around as the page loads.

3. TBT (Total Blocking Time): How much JavaScript blocks the main thread.

Sliders tend to touch all three, which is why they’re so easy to get wrong.

Here are 5 ways you can optimize your sliders for google

1. Choose a lightweight slider library (I prefer blaze sliders): Not all slider libraries are created equal. Some ship with large bundles, heavy dependencies, and features you’ll never use. You can check out the previous i_only_speak_liquid newsletter to get a few more recommendations.

2. Optimize images before blaming JavaScript (LCP): LCP issues are often image issues in disguise. Before touching javascript, check image size, format (use webp), and loading priority.

3. Only initialize sliders after the layout is stable: Let the browser initialize, ensure dimensions are calculated, then initialize the interaction.

4. Use CSS to prevent layout shift (CLS): CLS almost always comes from the browser not knowing how big something will be. If space is reserved before assets load, nothing jumps which leads to better CLS performance.

5. Load third-party scripts after the slider. For example if you need to load in review stars that relies on another app, initialize it after everything else has loaded in and use a placeholder (or skeleton) on load.

1 app I like:

Flexi: An app I’ve been building for almost two years that lets me drop professionally built sections into any client project. I got tired of rebuilding the same sections over and over, so I turned my workflow into a system I can reuse across sites.

3 links you can’t miss:

EyeDropper: For picking colors on websites

WhatFont: For finding fonts on websites

WhatRuns: For learning about how websites are built

One learning as a freelancer:

Manage expectations with clients right from the start. An old mentor once told me he only messages clients between 9–5. By being consistent, he “trains” clients to know when to expect responses, which protects his time, energy, and focus.

-Brandon