{% endblock %}
```
### Advanced Offline Page with Cached Content List
Show users what content is available offline:
```twig
{% extends 'base.html.twig' %}
{% block body %}
You're Offline
But you can still access these cached pages:
Loading cached pages...
{% endblock %}
```
## Creating Fallback Images
### SVG Offline Placeholder
Create a simple SVG offline image (`assets/images/offline.svg`):
```svg
```
### PNG Placeholder
For a more visual approach, create a branded offline placeholder image that matches your app's design.
## Use Cases
### Blog or News Site
```yaml
pwa:
serviceworker:
workbox:
offline_fallback:
page: 'app_offline'
image: 'images/article-placeholder.jpg'
```
### E-commerce Application
```yaml
pwa:
serviceworker:
workbox:
offline_fallback:
page: 'app_offline_shop'
image: 'images/product-placeholder.svg'
```
### Documentation Site
```yaml
pwa:
serviceworker:
workbox:
offline_fallback:
page: 'app_offline_docs'
# No image fallback needed - docs don't rely on images
```
## Testing Offline Fallbacks
### In Chrome DevTools
1. Open DevTools (F12)
2. Go to **Application** tab
3. In **Service Workers** section, check **Offline**
4. Navigate to a page not in cache
5. Should see your offline fallback page
### Clear Cache to Test
```javascript
// In DevTools Console
caches.keys().then(keys => {
keys.forEach(key => caches.delete(key));
});
```
Then test offline navigation.
## Best Practices
1. **Keep it simple**: Offline pages should have minimal dependencies
2. **Inline CSS**: Don't rely on external stylesheets that might not be cached
3. **Clear messaging**: Explain the offline state clearly to users
4. **Provide actions**: Include buttons to retry or navigate to cached content
5. **Match branding**: Keep the offline experience consistent with your app's design
6. **Test thoroughly**: Test various offline scenarios (page navigation, image loading, etc.)
7. **Monitor cache**: Ensure fallback resources are actually cached
## Fallback Priority
When a request fails:
1. **Try cache first**: Check if resource is in any cache
2. **Try network**: Attempt network request
3. **Use fallback**: If both fail, serve the appropriate fallback
This ensures fallbacks are truly a last resort.
{% hint style="info" %}
**Tip**: Combine offline fallbacks with [resource caching](/1.4.x/the-service-worker/workbox/resource-caching.md) and [precaching](/1.4.x/the-service-worker/workbox/asset-caching.md) strategies for the best offline experience.
{% endhint %}
## Troubleshooting
**Fallback not showing?**
* Verify fallback files exist and are accessible
* Check that files are being precached (DevTools → Application → Cache Storage)
* Ensure service worker is activated
* Test in incognito mode to rule out caching issues
**Fallback showing when it shouldn't?**
* Check your network conditions
* Verify cache strategies aren't too aggressive
* Look for JavaScript errors preventing network requests
{% hint style="success" %}
Start with just a page fallback. Once that works well, add image and font fallbacks as needed. Most apps only need a page fallback.
{% endhint %}
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://pwa.spomky-labs.com/1.4.x/the-service-worker/workbox/offline-fallback.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.