lighthouse optimizations for mobile

[tigawanna]

I'd like to start by thanking you for this amazing gem.
am trying to understand how SSR works and the best coach policy to get te best lighthouse scores
the desktop test is getting 99% but the mobile version is getting from 70 - 85%

I've already tried adding the headers recommended in that attached warnings
headers.ts

interface ResponseHeadersProps {
  /** Status code */
  status?: number | ((currentStatus: number) => number);
  /** The headers to set */
  headers?: Record<string, string | string[]> | ((headers: Headers) => void);
  /**
   * Time to hold the render stream before returning the response. Set to
   * true to hold until the page is fully rendered, effectively disabling
   * streaming.
   */
  throttleRenderStream?: number | true;
}


  export const headerConfig: ResponseHeadersProps = {
    headers: (headers: Headers) => {
      // headers.set('Access-Control-Allow-Origin', '*');
      headers.set('Cache-Control', 'max-age=31536000');
      headers.set('Accept-Encoding', 'gzip, compress, br');
      return headers;
    }

  }

root layout

export function headers(){
  return headerConfig
}

and they seem to have been set in the network tab

but the lighthouse warning still persists and the performance isn't improving
is there another way to optimize this for better performance

[cyco130]

Thank you for your interest.

This deserves it's own page in the docs. I'll try to answer in a few hours when I'm on my computer. Would you like to describe your deployment environment (VDS, serverless, edge etc.) in the mean time?

[tigawanna]

it's just Nodejs on a local build I haven't yet deployed it

[cyco130]

Caveat emptor

Node can handle TLS termination (https), HTTP/2, and compression. But before diving in, I think all these should be handled outside of Node by a reverse proxy like Nginx because they can handle all of these things more efficiently. So I would recommend you to leave the generated server alone and focus on optimizing your Nginx/Apache/whatever settings. I understand the urge to measure performance locally but I don't think the results are representative of the real world use in any way.

Optimizing static assets

Behind the scenes, Rakkas uses vavite to build a Node server for your application. In particular, it uses the @vavite/connect package. And @vavite/connect, in turn, uses sirv to serve static assets.

Caching

Lighthouse is complaining about the cache headers of your static assets, not your pages. The headers function sets the headers for pages, not static assets.

Rakkas generates three types of static assets. They all end up in dist/client when you build your app. The first type is the stuff copied verbatim from your public directory. The second type is the static assets that are the build output of your JavaScript, CSS, and other imported assets like fonts or images. The third type is the HTML files if you use static prerendering.

The first type (assets copied from the public dir) is for rarely changing files like robots.txt or favicon.ico. It's usually OK to cache them but overly aggressive caching may cause problems when you do want to change them. It's always frustrating to update your favicon but see that your users keep seeing the old one for weeks :)

The second type of assets always end up in the /assets/ path and have a content hash added to their names, so they have URLs like /assets/index-d8799502.js. If their contents change, the content hash (the d8799502 part) also change. So it's always OK to cache these ones aggressively.

The third type should not be cached too aggressively because they probably change on every deploy.

Rakkas allows you to set sirv options in your entry-node.ts file. If you create one, you also have to create a custom HatTip entry. You can install the sirv package to access the types.

The following sirvOptions settings should work for most cases:

src/entry-node.ts:

import { createMiddleware } from "rakkasjs/node-adapter";
import hattipHandler from "./entry-hattip";
import type { Options } from "sirv";

export default createMiddleware(hattipHandler);

export const sirvOptions: Options = {
  // E-tag is a good strategy for most files, including prerendered HTML
  etag: true,
  // For the files in assets dir, we can go wild, we can even specify immutable
  setHeaders(res, pathname) {
    if (pathname.startsWith("/assets/")) {
      res.setHeader("Cache-Control", "public, max-age=31536000, immutable");
    }
  },
};

Enabling compression

Like I said before, I believe we should leave compression to Nginx or similar. But you can use vite-plugin-compression to precompress static assets during build and configure sirv to look for precompressed .gz and/or .br files. The following config uses it twice to create both formats (it's probably OK to only provide brotli these days, but let's be on the safe side):

vite.config.ts:

import { defineConfig } from "vite";
import rakkas from "rakkasjs/vite-plugin";
import tsconfigPaths from "vite-tsconfig-paths";
import compression from "vite-plugin-compression";

export default defineConfig((env) => ({
  plugins: [
    tsconfigPaths(),
    rakkas(),
    // This plugin is only needed for the client build
    !env.ssrBuild && compression({ algorithm: "gzip" }),
    !env.ssrBuild && compression({ algorithm: "brotliCompress" }),
  ],
}));

Then you should update your sirvOptions to look for .gz and .br files:

// ...

export const sirvOptions: Options = {
+ gzip: true,
+ brotli: true,
  // E-tag is a good strategy for most files, including prerendered HTML
  etag: true,
  // For the files in assets dir, we can go even specify immutable
  setHeaders(res, pathname) {
    if (pathname.startsWith("/assets/")) {
      res.setHeader("Cache-Control", "public, max-age=31536000, immutable");
    }
  },
};

This doesn't precompress prerendered HTML files. We may add that as a feature but it's not a priority, because, like I said, I believe compression should be handled by the reverse proxy.

These changes should bring you closer to 100% score in your local environment. You can also add cache headers for your pages but be very careful adding aggressive cache control headers. Pages tend to be prone to change due to their very nature. max-age=31536000 in a page tells the browser to only look for updates once a year. It's almost never what you want for a web page.

[tigawanna]

Thank you so much for the elaborate answer this clears up a lot and will be very helpful