Performance begins with the details.
The right image. The right priority. Resources ready to be reused. A deliberate approach to how your website reaches the screen.
Explore the mechanisms ↓Built on Wulver. Measured by Google.
katyushyn.com is built on Wulver. Here is how its public homepage performed in Google PageSpeed Insights — with the actual reports behind every number.
Mobile
Performance score
- First Contentful Paint
- 1,5 s
- Largest Contentful Paint
- 1,6 s
- Speed Index
- 1,9 s
- Total Blocking Time
- 0 ms
- Cumulative Layout Shift
- 0
Moto G Power emulation · slow 4G
Open the mobile report ↗Desktop
Performance score
- First Contentful Paint
- 0,3 s
- Largest Contentful Paint
- 0,4 s
- Speed Index
- 0,8 s
- Total Blocking Time
- 0 ms
- Cumulative Layout Shift
- 0
Desktop emulation · custom throttling
Open the desktop report ↗All three additional categories scored 100 on both devices. These are laboratory results for https://katyushyn.com/ on its first load, captured on the date above. Scores can vary between runs. PageSpeed did not have real-user field data for this report.
A good experience respects the reader’s time.
A page begins to make an impression while it is still loading. The first image appears, the text finds its place, the interface becomes usable. Every unnecessary download and every unexpected movement adds friction to that introduction. Performance is part of the design of this moment.
Wulver approaches that experience through concrete mechanisms: responsive image variants, explicit loading priorities and cache policies for assets. These mechanisms work with the templates and deployment configuration. Their effect depends on the actual content, device, network and hosting environment.
The goal is practical: give the browser useful choices, avoid repeating work that has already been done and make important content available without competing equally with everything else on the page.
Every byte should earn its journey. Every first impression should arrive with purpose.
One source. A size that fits the moment.
A small avatar and a wide article cover do not need the same amount of image data. Wulver creates responsive AVIF variants through its existing thumbnail pipeline. Article images use target widths of 400, 700, 1000 and 1400 pixels, capped at the source width so smaller originals are not enlarged.
Variants are generated on first use and reused afterwards. The template receives the image candidates and information about their intended display size. Avatars, portraits and sliders have their own size sets, so the same principle can serve different parts of the interface.
The image pipeline preserves source files and creates derivatives separately. Source revision information participates in variant keys, allowing changed sources to receive fresh variant URLs. Preparing the variants before traffic arrives can also avoid the cost of first-use encoding on a visitor’s request.
A concrete example of a lighter delivery.
The Wulver image-optimization report records a bounded sample of four avatars and three article images. The comparison below sums one download per image and selects 96px avatar variants and 700px article variants.
Source: Wulver’s internal image-optimization report dated 25 October 2026. This is an image-transfer calculation for that sample, not a page-load speed measurement or a guaranteed saving. Actual selection depends on the screen and pixel density.
The first screen deserves a head start.
Loading order matters alongside file size. The responsive image tools distinguish priority images from deferred ones. In the Story templates, the first home slider image and article hero receive eager loading and high fetch priority; later or lower-page images can be lazy-loaded.
Prioritize what matters
The main image is identified explicitly so the browser has a priority hint. This is a deliberate template decision tied to the page composition.
Defer what can wait
Lazy loading gives lower-page images a different loading strategy. The first screen does not need every image in a long article to start equally early.
Reserve the space
Intrinsic width and height describe the image ratio before the file arrives. Combined with the layout, they help the browser allocate space for the image.
Let completed work stay completed.
Static resources with a memory
Wulver uses WhiteNoise and django-compressor in its asset workflow. Versioned static files and recognized compressor bundles can receive long-lived immutable cache headers. A stable versioned URL gives the browser a resource it can reuse under that policy.
A new version needs a clear address
Long caching requires a corresponding update strategy. Replace changed static resources through versioned URLs, and verify the headers served by the actual hosting layer. Media has a separate cache policy because uploaded files can have a different lifecycle.
When a proxy, web server or object storage serves the files directly, that layer controls the response headers. Application settings and deployment settings need to agree. The final verification belongs on the delivered CSS, JavaScript, font and image URLs.
Measure the page you actually deliver.
Smaller image files are one part of performance. Server response, styles, scripts, fonts and the page’s composition also influence the experience. Wulver supplies mechanisms to work with these resources; a meaningful assessment still needs the deployed page and representative viewing conditions.
- Inspect which image variant the browser downloads.
- Compare first visits and repeat visits with cache enabled.
- Check the first screen, image priorities and layout movement.
- Re-measure after changing content, templates or deployment settings.
Build an experience worth arriving at.
Performance grows from a chain of considered decisions: preserve the source, deliver a suitable variant, prioritize the first impression and reuse what can be reused. Wulver connects these decisions to the way the website is built and maintained. The next step is to test them with your own content.