How to improve performance
This guide describes ways to improve the loading and rendering performance of your marketplace.
When we think about page speed there are actually two different scenarios that we need to address:
- The speed of initial page load and possible reloads after that
- The speed of changing the page within Single page application (SPA)
Read more about website performance.
We haven't yet implemented code splitting to reduce initial page rendering time, but there're other improvements that could be done to improve both cases of page rendering.
- Check page performance
- Optimize image sizes
- Lazy load off-screen images and other components
- Use sparse attributes
- About code-splitting
The first step is, of course, to start measuring performance. Lighthouse is a good tool to check rendering performance. At least check those pages that are visible to unauthenticated users (e.g. landing page, search page, listing page, about page and other static pages).
Lighthouse will give you some tips about how to improve performance and other aspects that website developers should think about.
If your page is showing images, you should check that the image size is not bigger than what is needed. So, adjusting image dimensions is the first step, but you should also think about image quality, advanced rendering options and possibly serving those images from CDN instead of from within your web app.
- Check that the actual dimensions of an image match with DOM element's dimensions.
- Lighthouse suggests that image compression level should be 85% or lower. Read more
- Good rule-of-thumb is that use JPEG for images and photos, where PNG is better for graphics, such as logos, graphs and illustrations.
- If you are using JPEG images, think about saving them as progressive JPEGs. Read more + Photoshop guide
- If you are using PNG images, consider running them through PNG optimizers to reduce file size. Plenty of options available, one example is TinyPNG.com
- Think about serving images and other static assets from some CDN. Read more.
Another way of dealing with images is to lazy load those images that are
not visible inside an initially rendered part of the screen. Lazy
loading these off-screen images can be done with helper function:
SectionLocations component for details.
Another way to reduce the amount of data that is fetched from API is sparse attributes. This is a feature FTW has not yet leveraged fully, but it is created to reduce unnecessary data and speed up rendering. You can read more from Marketplace API reference for sparse attributes.
We haven't yet implemented code-splitting to template app. Our current
setup is creating one UMD bundle file that is used on both client-side
and server-side rendering (SSR). Unfortunately, Webpack (a bundling tool
sharetribe-scripts dependency) has
a bug that prevents
using code-splitting. This means that there need to be separate builds
for browser and SSR for code-splitting to work.
In practice, it is probably best to add another Webpack build
configuration for the server in Create React App (CRA) fork
sharetribe-scripts is a fork of CRA repo). That will also mean some
server/ folder as well as in
Furthermore, if you are considering code-splitting, you should also be aware that there might be a problem with a "back" navigation button. (If the page loads asynchronously, a browser might not be able to return the user to the correct scrolling position on the previous page.) We would also like to be aware if users of the template app are considering code-splitting - if there's more demand for this feature, we should prioritize it accordingly.