Only render changed files

[bryanwhiting]

On of the benefits of Hugo is how fast it is. I don't like how slow quarto is when rendering (taking several seconds to build + refresh). I wrote this script to scan for files that have changed locally compared to remote and only render those files. It takes the guesswork out of comparing changes.

library(dplyr)
library(stringr)
files <- system("git diff main origin/main --name-only -- . :^docs", intern=T) %>% 
    tibble(files=.) %>% 
    filter(str_detect(files, 'md$')) %>% 
    pull(files)

if(length(files) > 0){
  cat(
    paste0('Rendering uncommitted *.md files:\n\t', 
           paste0(files, collapse ="\n\t")
    ), 
  "\n")
  for(f in files){
    cmd <- paste0("quarto render --quiet ", f)
    print(cmd)
    system(cmd)
  }
}

[mcanouil]

Did you try execute.freeze?
See https://quarto.org/docs/projects/code-execution.html#freeze

[bryanwhiting]

Yes, didn't "skip" the file like I had hoped when running a blanket "quarto render"

…

On Wed, Dec 14, 2022 at 12:29 PM Mickaël Canouil ***@***.***> wrote: Did you try execute.freeze? See https://quarto.org/docs/projects/code-execution.html#freeze — Reply to this email directly, view it on GitHub <#3674 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEOYC64MMEFHWYFBGWB6LRLWNIU4JANCNFSM6AAAAAAS647JV4> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[bryanwhiting]

I have execute.freeze set in both about.qmd and posts/...file.qmd and it still spends several seconds rendering all these files.

---
title: "About"
image: img/profile.jpg
execute:
    freeze: true

[dragonstyle]

This is expected as freeze is really designed to freeze execution of the code in the QMD (versus the actual rendering of the document). Huge is definitely faster than Quarto and we currently have erred on the side of caution and made render always render the full site to ensure that the output always reflects the current saved input state.

This would be a good area for us to improve over time...

[bryanwhiting]

yes, i assumed this was expected. What's the rationale for rendering files that haven't changed? I'd image a quarto render --all or --force would be an expected behavior to render all posts and quarto render to just do those that have changed.

[dragonstyle]

I think it's less about a principled position and more that we don't currently have a reliable enough render state to know that the input file hasn't changed. As a result, we always render. I think it would be something we'd like to get better / faster at!

[bryanwhiting]

ahh, makes sense. Thanks for taking this into consideration! love the work you're doing. I considered moving back to hugo because the rendering was slow (I miss Live Reload), but Quarto has so many rich features that this is one I can do without for now :) Thanks for all you're building!

[mcanouil]

The freeze option is a project option: "Note that freeze controls whether execution occurs during global project renders."

This might also be related to #3661

[bryanwhiting]

yes, that speaks to it

[cscheid]

That's a neat script. Making quarto faster is definitely on our radar and there's some incoming improvements in 1.3.

With regards to re-rendering, we're currently being conservative on quarto render because of possible dependencies. As a simple example, listings can use content from other files, and so a simple diff-based approach won't always work.

If you're working interactively on a large quarto project, then quarto preview can offer a better experience than quarto render everything all the time: the preview command will render everything once, but then will only refresh the changed files.

[bryanwhiting]

Thanks, I haven't been using quarto preview when I now realize I should be. The problem is that quarto preview wasn't working inside my docker container and so I went with this approach. Maybe I just need to figure out why it's not working in my docker image.

[bryanwhiting]

I tried

Preparing to preview

Watching files for changes
http://localhost:3000/

and I have the port mounted:

docker run \
	--detach \
	--publish 80:8787 \
	--publish 3000:3000 \
	--env DISABLE_AUTH=true \
	--name renv \
	--volume $GH/blog:$ROOT/blog \
	rocker/tidyverse

but when I go to localhost:3000 I just get:

This page isn’t workinglocalhost didn’t send any data.
ERR_EMPTY_RESPONSE

[mcanouil]

See #2083

[josherrickson]

If you're working interactively on a large quarto project, then quarto preview can offer a better experience than quarto render everything all the time: the preview command will render everything once, but then will only refresh the changed files.

Is there a technical reason that either quarto render can't be given an option to operate like quarto preview (just in terms of only re-rendering changed files), or that quarto preview can't be given an option to re-render then exit without keeping running? I've tried adding the the various --no- options, and --timeout 0/--timeout 1 but can't seem to make it happen. The use case is to replace quarto render to just build the site, without having the Ctrl-C afterwards.

[ThSGM]

That's a neat script. Making quarto faster is definitely on our radar and there's some incoming improvements in 1.3.

With regards to re-rendering, we're currently being conservative on quarto render because of possible dependencies. As a simple example, listings can use content from other files, and so a simple diff-based approach won't always work.

If you're working interactively on a large quarto project, then quarto preview can offer a better experience than quarto render everything all the time: the preview command will render everything once, but then will only refresh the changed files.

It's been a couple of years since this was raised, and despite my searching around these parts, I'm not sure this was ever addressed.

I have a Quarto book that includes about 30 chapters, say. This is rendered into PDF so needs to run through xelatex. In order to view the PDF file, I need to re-render the complete document each time!

[royfrancis]

This is extremely useful in a project with large number of files and collaborators.

In addition to freezing code execution, there must be an option to freeze rendering of files in a project. Something like

render:
    freeze: true

Another idea is to have it linked to format to allow selective freezing of specific formats in a project. Something like

format:
  html:
    freeze: true

I totally understand the concern "we don't currently have a reliable enough render state to know that the input file hasn't changed". But, leave that to the user to decide whether they want to use this option and take the risk.

[allefeld]

I second this. Make it a YAML option or a command line option, e.g. --only-changed.

Use case: I have a Quarto website which contains a large number of source files. I usually only change one of them at a time, but all get rendered which takes a lot of time. That's unnecessary because there are no dependencies between them.

quarto preview may serve as a hack in the meantime, but it doesn't exactly provide the needed functionality, because it is watching for file changes.

[allefeld]

Plus, this is also nicer for VCS. This way, all html files are updated in every commit.

[mcanouil]

To note, the following "epic" issue should help with this:

• Epic: Execution Planner #6518

[bryanwhiting]

thanks!

[HaykTarkhanyan]

@bryanwhiting Thank you for the script. It saves a lot of time for me.

[bryanwhiting]

Glad it's still helping out all these years later! Thanks, Bryan

…

On Sun, Aug 17, 2025 at 1:14 PM Aik Tarkhanyan ***@***.***> wrote: @bryanwhiting <https://github.com/bryanwhiting> Thank you for the script. It saves a lot of time for me. — Reply to this email directly, view it on GitHub <#3674 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEOYC6YO6U3BVAO3FQH3W5T3ODPEBAVCNFSM6AAAAABWAZMV72VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIMJTGM4TIMQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>