Closed Bug 1678956 Opened 4 years ago Closed 2 years ago

SVG sprite rendering blinking on multiple reloads of the page [apparently due to not using cached resources]

Categories

(Core :: Networking: Cache, task, P3)

Firefox 83
Desktop
All
task

Tracking

()

RESOLVED INVALID
Tracking Status
firefox83 --- affected
firefox84 --- affected
firefox85 --- affected

People

(Reporter: robsworld2006, Unassigned)

References

Details

(Whiteboard: [necko-triaged])

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:83.0) Gecko/20100101 Firefox/83.0

Steps to reproduce:

Using Windows Firefox 83

Go to this page: http://acf.foundation/wp-content/uploads/fontawesome5/docs/svg-sprite.html

Wait for the page to load, then reload the page again F5

Actual results:

On the first page load, the svg sprites load.
On a page refresh, the icons seem to blink as they have to be re-rendered causing a delayed blinking issue.

This causes layout shift.

Expected results:

I would assume since the svg sprite is cached, so it should render the icons instantly.

On Firefox Mobile (IOS) the icons come up instantly without blink, rendering instantly

On Chrome and Edge they work instantly too.

This behavior is also seen in the Chrome browser, so I would consider that it is not a browser issue. Furthermore, I can also observe this issue on an android device using v85.0a1-20201124; I don't have an iOS device to compare with.
Furthermore, I do not understand how page rendering works, so I will set this bug's component as (Core) SVG and let it be picked up by a person with more technical skill in this area.

Thank you for your contribution!

Component: Untriaged → SVG
OS: Unspecified → All
Product: Firefox → Core
Hardware: Unspecified → Desktop

The site responds with

Cache-Control max-age=0

If the images should be cached the site should say so.

Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → INVALID

I just double checked in Chrome and other browsers like Edge and I can see that the icons come up straight away.

I did check the header of the SVG:
Accept-Ranges: bytes
Cache-Control: max-age=691200
Connection: keep-alive
Content-Encoding: gzip
Content-Type: image/svg+xml

To truly test this you must load the page, then press F5 to reload the page.
You will see in chrome, edge and other browsers the icons are rendered pretty quickly. In Firefox there seems to be a slight delay hence you get FONI effect where icons blink.

I've added some animated GIFs to highlight the issue
Chrome: https://ibb.co/MDPYxzh
Firefox: https://ibb.co/WGNq86c

Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---

I can confirm that I see Cache-Control: max-age=691200 in the response for the resources (e.g. solid.svg), so I'm not sure why we're not using a cached resource when reloading the page.

Moving this to Networking:Cache, as it seems more like it's at that level rather than SVG rendering.

Component: SVG → Networking: Cache
Summary: SVG sprite rendering blinking on multiple reloads of the page → SVG sprite rendering blinking on multiple reloads of the page [apparently due to not using cached resources]

VALIDATE_ALWAYS flag is set and that cause necko to validate cache entry. The server return 200 response.
VALIDATE_ALWAYS is set when we do refresh.
It looks like Chrome is serving response from memory cache and it is not validating it.

We could look into improving this, but we need to understand Chromes behavior first.

Severity: -- → N/A
Type: defect → task
Priority: -- → P3
Whiteboard: [necko-triaged]

Hi all, just wondering if there has there been any further investigation into how Chromes behaviour works?

See Also: → 1027106

On Firefox 90.0a1 (2021-05-16) (64-bit)

The sprite giving the icons has Cache-Control: max-age=691200
http://acf.foundation/wp-content/uploads/fontawesome5/sprites/solid.svg

The HTTP response is:

HTTP/1.1 200 OK
Content-Type: image/svg+xml
Transfer-Encoding: chunked
Connection: keep-alive
Keep-Alive: timeout=15
Date: Thu, 20 May 2021 04:33:55 GMT
Server: Apache
Last-Modified: Mon, 11 Sep 2017 17:32:27 GMT
ETag: "62293-558ed4f7340c0-gzip"
Accept-Ranges: bytes
Cache-Control: max-age=691200
Expires: Fri, 28 May 2021 04:33:55 GMT
Vary: Accept-Encoding
Content-Encoding: gzip

Each reload generates a 200 HTTP response.

The main page has Cache-Control: max-age=0
http://acf.foundation/wp-content/uploads/fontawesome5/docs/svg-sprite.html

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 51148
Connection: keep-alive
Keep-Alive: timeout=15
Date: Thu, 20 May 2021 04:33:54 GMT
Server: Apache
Last-Modified: Mon, 11 Sep 2017 17:21:11 GMT
ETag: "171bb1-558ed27284fc0-gzip"
Accept-Ranges: bytes
Cache-Control: max-age=0
Expires: Thu, 20 May 2021 04:33:54 GMT
Vary: Accept-Encoding
Content-Encoding: gzip

Inside that page the icons are called with use xlink:href

<a href="https://github.com/FortAwesome/Font-Awesome-Pro/tree/master/svgs/solid/address-book.svg" target="_blank" class="color-inherit link">
  <svg class="icon">
    <use xlink:href="../sprites/solid.svg#address-book"></use>
  </svg>
</a>

Another experiment, just loading the SVG by itself.
http://acf.foundation/wp-content/uploads/fontawesome5/sprites/solid.svg

And doing a reload, and Firefox reloads the resource even the ETAG has not changed.

Edge Version 92.0.892.0 (Version officielle) Canary(x86_64)

Same http headers. and the response is also HTTP 200 on reload
But the reload takes the resources from the memory cache.

Safari Release 124 (Safari 14.2, WebKit 16612.1.11.10)

Same thing than Edge taking solid.svg from memory

need more testing.

fwiw, the server acf.foundation responds always with a 200
https://www.acf.foundation/wp-content/themes/yootheme/cache/ACF-Logo-fdbced7b.png

HTTP/2 200 OK
content-type: image/png
content-length: 11657
date: Fri, 21 May 2021 08:02:59 GMT
server: Apache
last-modified: Sat, 09 May 2020 11:02:08 GMT
etag: "2dd8-5a5350b8070d4-gzip"
accept-ranges: bytes
cache-control: max-age=691200
expires: Sat, 29 May 2021 08:02:59 GMT
vary: Accept-Encoding
content-encoding: gzip
X-Firefox-Spdy: h2

while the request was

GET /wp-content/themes/yootheme/cache/ACF-Logo-fdbced7b.png HTTP/1.1
Host: www.acf.foundation
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:90.0) Gecko/20100101 Firefox/90.0
Accept: image/webp,*/*
Accept-Language: en,en-US;q=0.8,fr;q=0.5,fr-FR;q=0.3
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Referer: https://www.acf.foundation/updates/
Sec-Fetch-Dest: image
Sec-Fetch-Mode: no-cors
Sec-Fetch-Site: same-origin
If-Modified-Since: Sat, 09 May 2020 11:02:08 GMT
If-None-Match: "2dd8-5a5350b8070d4-gzip"
Cache-Control: max-age=0

The date was not modified, the if-none-match was not modified.
Still the server is sending a 200 instead of 304 Not Modified. Mis-configured apache server?

And if I put the solid.svg file on my own server with similar header, the HTTP caching is working. (the blinking is still here)

Are you reporting only for this server, or did you find a similar issue on a different server?

Flags: needinfo?(robsworld2006)

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

Status: UNCONFIRMED → NEW
Ever confirmed: true

Redirect a needinfo that is pending on an inactive user to the triage owner.
:dragana, since the bug has recent activity, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(robsworld2006) → needinfo?(dd.mozilla)

According to comment 8 this looks like a server issue. We have not got an answer from the reporter if it is happening with a different server so we will close the issue.

Status: NEW → RESOLVED
Closed: 4 years ago2 years ago
Flags: needinfo?(dd.mozilla)
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.