Merge 227288d12b into 91d7ae8a6e

docs/advanced_topics/images/image_serve_view.md

@@ -123,7 +123,7 @@ urlpatterns = [
 [django-sendfile](https://github.com/johnsensible/django-sendfile) offloads the job of transferring the image data to the web
 server instead of serving it directly from the Django application. This could
 greatly reduce server load in situations where your site has many images being
-downloaded but you're unable to use a [](caching_proxy) or a CDN.
+downloaded but you're unable to use a [caching proxy](performance_frontend_caching) or a CDN.
 
 You first need to install and configure django-sendfile and configure your
 web server to use it. If you haven't done this already, please refer to the

docs/advanced_topics/performance.md

@@ -60,14 +60,16 @@ The same can be achieved in Python using [`generate_image_url`](dynamic_image_ur
 
 When using a queryset to render a list of images or objects with images, you can [prefetch the renditions](prefetching_image_renditions) needed with a single additional query. For long lists of items, or where multiple renditions are used for each item, this can provide a significant boost to performance.
 
-(performance_page_urls)=
+(performance_frontend_caching)=
 
-## Frontend caching
+## Frontend caching proxy
 
-Many websites use a frontend cache such as Varnish, Squid, Cloudflare or CloudFront to gain extra performance. The downside of using a frontend cache though is that they don't respond well to updating content and will often keep an old version of a page cached after it has been updated.
+Many websites use a frontend cache such as [Varnish](https://varnish-cache.org/), [Squid](http://www.squid-cache.org/), [Cloudflare](https://www.cloudflare.com/) or [CloudFront](https://aws.amazon.com/cloudfront/) to support high volumes of traffic with excellent response times. The downside of using a frontend cache though is that they don't respond well to updating content and will often keep an old version of a page cached after it has been updated.
 
 Wagtail supports being [integrated](frontend_cache_purging) with many CDNs, so it can inform them when a page changes, so the cache can be cleared immediately and users see the changes sooner.
 
+(performance_page_urls)=
+
 ## Page URLs
 
 To fully resolve the URL of a page, Wagtail requires information from a few different sources.
@@ -88,14 +90,6 @@ Wagtail is tested on PostgreSQL, SQLite, and MySQL. It may work on some third-pa
 
 We recommend PostgreSQL for production use, however, the choice of database ultimately depends on a combination of factors, including personal preference, team expertise, and specific project requirements. The most important aspect is to ensure that your selected database can meet the performance and scalability requirements of your project.
 
-(caching_proxy)=
-
-## Caching proxy
-
-To support high volumes of traffic with excellent response times, we recommend a caching proxy. Both [Varnish](https://varnish-cache.org/) and [Squid](http://www.squid-cache.org/) have been tested in production. Hosted proxies like [Cloudflare](https://www.cloudflare.com/) should also work well.
-
-Wagtail supports automatic cache invalidation for Varnish/Squid. See [](frontend_cache_purging) for more information.
-
 ### Image attributes
 
 For some images, it may be beneficial to lazy load images, so the rest of the page can continue to load. It can be configured site-wide [](adding_default_attributes_to_images) or per-image [](image_tag_alt). For more details you can read about the [`loading='lazy'` attribute](https://developer.mozilla.org/en-US/docs/Web/Performance/Lazy_loading#images_and_iframes) and the [`'decoding='async'` attribute](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/img#attr-decoding) or this [web.dev article on lazy loading images](https://web.dev/lazy-loading-images/).