test

[pieh]

Gatsby currently eagerly runs all the queries in development mode. This results in longer and longer boot times for the development server as the amount of content/pages increases.

In [email protected] we introduced experimental Query on demand feature that doesn't eagerly run all the page queries in development mode. Instead of running those eagerly, we will run them when the user actually navigates to a page in a browser (but only if we didn't run the query yet, or if the result is not up to date - for example after changing content used to generate query results). We continued working on it and were releasing incremental improvements with each release.

In [email protected] we started partial rollout and enabled this feature for randomly selected portion of repositories. If your repository was selected and you want to opt out of this behaviour you can add flags: { QUERY_ON_DEMAND: false } to your gatsby-config.js. If you do that please let us know in comment what caused decission to not use it - we want to address those issues! If your repository wasn't selected - read on - you can manually enable it.

How to test & help out

Make sure you are using at least 2.29.0 version of gatsby. Try out the feature on your site by adding flags: { QUERY_ON_DEMAND: true } to your gatsby-config.js (here's example - pieh/gatsby-starter-blog@ef0aced) and run gatsby develop

Report any errors or other problems you might see. Please also check "Known Deficiencies" below to check for known issues, limitations and additional future work planned for this feature.

We'd love also for you to report if you see improvements on your site and if you do then how much faster it is!

What can you expect?

If run page queries step is taking a long time when you initially run gatsby develop (or later on when server is already up and you edit your content and/or queries), you can expect this step to drop significantly. We still do run queries for some pages eagerly, but those are just 404 pages and index page for initial start.

Be aware that depending on how heavy your page queries are - you might see some increased loading time for pages that don't have up-to-date query results. This leads to another point - we don't run queries unconditionally on each page load! Gatsby does keep track of when queries actually need to rerun. They will rerun when data used for page actually changed or when you edit page query. This means that after we do run query for a page we will reuse those cached results for as long as we can.

Loading indicator

We did add loading indicator (in gatsby develop only! It will not show up in production builds.) for cases when running query take longer than a second. Here's little demo of it:

We do automatically disable showing this indicatator when running in cypress environment ( to make sure this UI element doesn't interfere with your end-to-end tests workflows).

We also allow to disable it for current gatsby develop session by visiting http://localhost:8000/___loading-indicator/disable endpoint in case it interfere in other scenarios (note you can also re-enable it later by using http://localhost:8000/___loading-indicator/enable). We also added friendly debug log in browser console after first time it is shown (we did set message to debug level so you might need to adjust log filtering in your browser - we don't want to spam your browser console):

Image processing

If you do use gatsby-plugin-sharp (either through gatsby-transformer-sharp, gatsby-remark-images and/or plenty of other ways sharp image processing is triggered) this is often one of most heavy work that happens. Using Query on Demand helps in sense that we can skip even starting the work on all the image processing by just not running all page queries that would trigger said processing. But we still need to do this work for pages that you will visit. But we have good news here! Check out Lazy Image Processing in gatsby develop that applies similar mechanism for image processing. While implementation wise Lazy Image Processing is "separate" project, using it together with Query on Demand is what we recommend - Query on Demand will prepare the data for page when you navigate to it and Lazy Image Processing will trigger image processing when browser actually need to display those images (so when they are in viewport or "close to" viewport).

Known Deficiencies

Passing data via page context:

If you query for content in gatsby-node.js and pass that data via page context (either completely skipping page queries or using mix of page context and page queries), then this feature might have no (or limited) impact. In particular:

• querying for excerpts (remark/mdx), html(remark), body(mdx)
• image processing (sharp)
• any other that do require some heavy/time consuming processing in gatsby-node

is not something that this feature can skip, because they are not part of page query running (querying them in page queries and NOT in gatsby-node.js is where this features shines actually!).

If you are passing your data via page context - consider trying out migrating to using page queries. Historically this was done to workaround performance issues when dealing with large amount of data (page queries were slower than doing single huge query in gatsby-node and chunking data programmatically), but there was lot of improvements there since this workaround started seeing a lot of use. Just to illustrate - see #20729 change in particular and broader list that expanded perf improvements making the use of this workaround not needed anymore.

Mdx

gatsby-plugin-mdx currently needs to do a lot of processing already at data sourcing time. There still should be visible improvement when mdx is used via page queries with this feature (running page queries still benefits from it, just overall it's not as drastic due to other bottlenecks)

Static queries and 404 page queries

First, let me make sure this is communicated - those do work, they are just not "on demand". This means we still eagerly will pre-run all static queries as well as 404 and Gatsby's development 404 page ( https://www.gatsbyjs.com/docs/add-404-page/ ). Reason for this is that making all kind of queries work on demand requires more refactors and changes than what we managed to do so far (but it's doable!). Think of it as progressive shipping of the feature that provide more and more value in each step without waiting to cover all possible improvements and make one huge splash (at much later date).

Data fetch request can occasionally stall for longer than time it takes to generate query results

The data requests can sometimes stall and actually take much longer than query result generation itself. This seems to happen when query running takes longer than 5 seconds (could be heavy query - for example including lots of image processing, could be result of some concurrent work like webpack recompilation, etc). See gatsbyjs#28184

Running queries on demand trigger query extraction each time

On some sites query extraction step adds noticable delay between requesting data and receiving it. We are working on skipping this step when possible ( see gatsbyjs#28595 )

Updates history

15 Dec 2020

Loading indicator released in stable 2.29.0. Partial rollout (mode is being enabled for randomly selected portion of repositories) started.

11 Dec 2020

Added loading indicator ( gatsbyjs#28562 ). Loading indicator will be included in [email protected] stable release, it is available in gatsby@next tag now

04 Dec 2020

Added ability to turn feature on via gatsby-config.js

19 Nov 2020

After a lot of fixes, more testing and various optimisations, Query on Demand ships to stable release (2.27.0) behind opt-in GATSBY_EXPERIMENTAL_QUERY_ON_DEMAND feature flag. It has few known issues (that are documented above) that will be addressed in future minor and patch releases. We feel it's good enough to invite more people to try it out and share their feedback about it (including bug reports!)

23 October 2020

Initial gatsby@qod canary version released. It had quite few issues as reported in gatsbyjs#27620 (comment)