Make Jamstack Slow? Challenge Accepted.

"Jamstack is slowwwww." You rarely hear that, especially given Jamstack's reputation for speed. However, even Jamstack sites can suffer performance issues. Don't assume Jamstack automatically equals blazing-fast performance; smart choices are crucial. Let's explore how poor decisions can cripple a Jamstack site's speed.

We'll intentionally build a slow Gatsby site to understand performance bottlenecks. Using continuous performance testing and Google Lighthouse, we'll track every change, starting with a perfect Lighthouse score of 100 and deliberately degrading it to a dismal 17.

Building Our Slow Jamstack Site

We'll use Gatsby. First, install the Gatsby CLI:

npm install -g gatsby-cli

Create a new Gatsby site:

gatsby new slow-jamstack

Navigate to the project directory and start the development server:

cd slow-jamstack
gatsby develop

For Lighthouse testing, we need a production build. Vercel provides a convenient hosting solution. Install and log in to the Vercel CLI:

npm install -g vercel-cli
vercel

This deploys the site to Vercel. A default Gatsby site is typically fast, scoring 100 on Lighthouse. Let's see how we can sabotage that.

Slowing Down with CSS

CSS frameworks are powerful, but choosing the wrong one or using it inefficiently can hurt performance. Opt for modular frameworks or CSS-in-JS to load only necessary styles.

We'll make a poor choice: loading the entire SemanticUI framework, including jQuery (a dependency), directly into the of our HTML. This requires copying the default html.js file:

cp .cache/default-html.js src/html.js

Then, add the SemanticUI stylesheet and jQuery to src/html.js:

<link href="https://cdn.jsdelivr.net/npm/%5Bemail%C2%A0protected%5D/dist/semantic.css" rel="stylesheet">

Deploy the changes:

vercel --prod

The Lighthouse score drops to 66, a significant decrease simply from loading unnecessary CSS. Time to Interactive (TTI) increases dramatically.

Slowing Down with Marketing Dependencies

Let's add Google Analytics and Facebook tracking scripts to src/html.js within the :

<!-- Google Analytics -->
<!-- Facebook Pixel -->
<img  src="/static/imghwm/default1.png" data-src="https://img.php.cn/?x-oss-process=image/resize,p_40" class="lazy"    style="max-width:90%"  style="max-width:90%" alt="Make Jamstack Slow? Challenge Accepted." >

Deploy again:

vercel --prod

The score plummets to 51. These seemingly small scripts have a substantial performance impact.

Slowing Down with Images

We'll add 100 images from https://placeimg.com to index.js, loading them directly without optimization:

const IndexPage = () => {
  const items = Array.from({ length: 100 }, (_, i) => (
    <img key="{i}" src="%7B%60https://placeimg.com/200/200/%24%7Bi%7D%60%7D" alt="{`Image">
  ));

  return (
    <layout>
      {items}
    </layout>
  );
};

Deploying again results in a drastically slow site, with a Lighthouse score of 17 and a TTI of 16.5 seconds.

The point? Every decision affects performance. Even on Jamstack, performance isn't free.

Restoring Speed

Jamstack's primary performance advantage is edge caching of static files, reducing Time to First Byte (TTFB). This is faster than server-side rendering. However, client-side optimizations remain essential. While high Lighthouse scores are desirable, remember that they don't always perfectly reflect user experience. This exercise demonstrates that even with Jamstack, diligent attention to performance is required.

The above is the detailed content of Make Jamstack Slow? Challenge Accepted.. For more information, please follow other related articles on the PHP Chinese website!