Skip to main content

5 releases tagged with "webops"

View All Tags

· 2 min read

WebOps now supports Incremental Static Build (ISB), a hybrid server-side and client-side rendering solution. With ISB, only part of the pages are generated during the website build. The others are generated as shoppers start visiting them.

In practice, the first user to load a page triggers its generation. And, once the first load completes, the final page is cached. Then, all subsequent visitors receive the cached version of that page immediately and experience an optimized page loading time.

info

This feature is strongly recommended for stores with thousands of SKUs since generating all SKU pages during the website build may be very time-consuming.

What has changed?​

To improve the loading time of SKU pages, you can now activate Incremental Static Build for your FastStore project. Part of the store's pages will be generated in each build, but the SKU pages will follow the Incremental Static Build behavior described above.

caution

Keep in mind that:

  • A deploy resets the caching status of all pages, meaning that pages previously generated must be requested again in order to be re-generated.
  • Once a page is generated, it will not be re-generated by external content changes. For example, if you edit a given product's description in the VTEX platform, you must redeploy your website to generate the page with the updated description.

What needs to be done?​

In order to activate this capability, follow these steps, according to the framework used in your project.

Gatsby​

  1. Open your FastStore project and update all pages requesting server data to use the following cache-control headers:
return {
status: 200,
props: data ?? {},
headers: {
'cache-control': 's-maxage=31536000, stale-while-revalidate',
},
}
  1. Set the following variable to true on your vtex.env file:
vtex.env
USE_STALE_CACHE=true

Next.js​

  1. Open your FastStore project and update all pages requesting server data to use the getStaticProps and getStaticPaths APIs.
  2. Set the following variable to true on your vtex.env file:
vtex.env
USE_STALE_CACHE=true

· One min read

Next.js and Gatsby projects deployed with WebOps can now benefit from faster builds. WebOps now counts with a caching system, which avoids the expensive work of regenerating unchanged files.

What has changed?​

WebOps can now reuse outputs produced from previous builds. This change reduces the number of requests for external services and, consequently, decreases building time.

Why did we make these changes?​

These improvements aim to reduce WebOps overhead by enhancing the generation, saving, and deployment of compilation artifacts while also decreasing build time. For example, after implementing these changes, it was possible to notice a decrease from 63s to 34s in the building time of the Base Store (Next.js).

What needs to be done?​

Set the following variables to true in the vtex.env file of your FastStore project:

vtex.env
USE_NODE_MODULES_CACHE=true
USE_FRAMEWORK_CACHE=true

· One min read

Now every deploy preview will have a new Lighthouse Reports box with quick-access links to reports for all pages you have listed in the Lighthouse CI section of the store.config.js file. That way, you can easily track how each pull request impacts the performance, SEO, and accessibility of your store.

What has changed?​

The Lighthouse CI now makes generated Lighthouse Reports available for developers via Google Lighthouse Viewer for each deploy preview and uploads them to AWS S3. WebOps, then, adds comments on new PRs with links to those reports.

Links to these reports are also shared in the logs of the WebOps pipeline for Lighthouse.

Why did we make these changes?​

These changes aim to make it simpler for you to track how each deploy affects your website's performance.

What needs to be done?​

Nothing. This improvement is already available for all WebOps users. Enjoy!

· One min read

The WebOps pipeline has been updated to use the newest Lighthouse version. In November 2021, Google published Lighthouse version 9.0. Among its main changes, highlights include the upgrade of Lighthouse APIs, the introduction of new user flows, the redesign of Lighthouse reports, and the addition of new accessibility features.

What has changed?​

Before, the WebOps pipeline was using Lighthouse version 8. Now, we are using Lighthouse 9. As a result, newer audit reports may slightly differ from those previously issued. For more information, please refer to this announcement.

Why did we make these changes?​

We understood that getting different results from WebOps and Lighthouse could lead to misunderstandings, so we made this modification to match both results.

What needs to be done?​

These changes are already available for everyone. Thus no further action is required to use WebOps with Lighthouse 9.

· One min read

Hello WebOps users,

With the increased number of concurrent users of the WebOps platform, we noticed WebOps pipelines were taking longer to execute. Under high loads, workflows that used to take from 2 to 10 minutes started to span between 20 and 50 minutes. This caused CMS publications to take longer than they should, harming the developer experience.

Earlier this week, we began an investigation into it, and we managed to improve the situation drastically. Our pipelines runtime is now back to the 2-10 minutes range, depending on the workload type and size of the store.

We are working hard to deliver improvements to our platform such as this. Expect further improvements during the closed beta as we work on our platform's stability and performance!