Astro 7.1 (16 lipca 2026) wygląda jak wydanie quality-of-life: brak zmian łamiących, aktualizacja przez npx @astrojs/upgrade. Ale changelog warto czytać jak mapę tego, gdzie użytkownicy Astro naprawdę odczuwają ból - i dwie z sześciu funkcji wskazują to samo miejsce: kolekcje treści, które urosły.
deferRender: truena loaderzeglob()odracza renderowanie Markdownu do momentu, gdy strona go potrzebuje, tnąc zużycie pamięci przy synchronizacji dużych kolekcji - kosztem utraty cache’owania wyrenderowanego HTML między buildami.experimental.collectionStorage: "chunked"dzieli dane kolekcji na pliki co 10 MB, obchodząc platformowe limity rozmiaru pojedynczego pliku.- CSP dostaje cztery drobniejsze dyrektywy (
script-src-elem/-attr,style-src-elem/-attr), więc można dopuścić style inline bez rozluźniania polityki dla zewnętrznych skryptów. paginate()przyjmuje callbackformat(np. dopisanie.htmlpod hosting statyczny), a--ignore-lockpozwala odpalić drugi serwer deweloperski obok działającego.
Ujęcie StackCompass: release notes to wyprzedzający wskaźnik realnego profilu obciążenia frameworka. Astro latami sprzedawało kolekcje treści jako odpowiedź dla stron contentowych; 7.1 to wersja, w której “kolekcja nie mieści się już w pamięci” stało się na tyle powszechne, że dowieziono dwie mitygacje. To nie zarzut wobec Astro - to dowód, że architektura jest używana na poważną skalę, i przypomnienie, że z trade-offami build-time, nie z marketingiem frameworka, będziesz żyć po starcie. Jeśli twoje kolekcje liczą tysiące wpisów, deferRender to flaga do zbenchmarkowania w pierwszej kolejności - a niesiony przez nią koszt utraty cache’u HTML to dokładnie ten rodzaj ceny, którego nigdy nie widać w ogłoszeniu o nowych funkcjach.
Źródło: astro.build