Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Safari cache on dev #5860

Closed
nickerlan opened this issue Dec 11, 2018 · 15 comments · Fixed by #6183
Closed

Safari cache on dev #5860

nickerlan opened this issue Dec 11, 2018 · 15 comments · Fixed by #6183

Comments

@nickerlan
Copy link

nickerlan commented Dec 11, 2018

The context
Safari 12.0.1
nextjs in dev mode
/pages/index.js with simplest react code:

import React from 'react'

class PageIndex extends React.Component{
    constructor(props){
        super(props)
    }
    render(){
        return (<div>123</div>)
    }
}
export default PageIndex;

Behaviour

  1. I change text to 1234
  2. Change blinks to 1234 and gets back to 123
  3. In network I see "in memory" near index.js
  4. This little icon in network, develop->empty caches, option + cmd + R, alltogether has no impact on this fact
@timneutkens
Copy link
Member

I can't reproduce this issue, tried on codesandbox: https://codesandbox.io/s/l2zqw773kz

@exogen
Copy link
Contributor

exogen commented Dec 11, 2018

@timneutkens It's definitely an issue, I can repro it too.

@exogen
Copy link
Contributor

exogen commented Dec 11, 2018

CodeSandbox is not really an accurate reproduction of how people run development mode. For example, clearly CodeSandbox is running everything through some kind of HTTPS proxy, because that hello world page is served over HTTPS right? But the dev server you get when you run next dev does not serve up via HTTPS, and HTTPS is something that could easily be influencing the browser's caching decisions.

@exogen
Copy link
Contributor

exogen commented Dec 11, 2018

I did some experiments and here's what I found:

  • The <link rel="preload"> that Next.js adds for resources like pages/index.js greatly affects how Safari decides to honor cache headers like Cache-Control.
  • When I remove the preload completely, Safari will correctly get the script every time.
  • When I add crossorigin="anonymous" to the preload, Safari doesn't refetch it every time, but appears to bust its own cache (which shouldn't exist for the file in the first place) after a few seconds, so more refreshes do eventually refetch it (instead of never refetching).

This is most likely an issue with Safari's preload handling unless there's some special cache handling defined for preload that I'm not aware of. But, it would be nice if Next.js were aware of real-world issues like this and worked around them. Is preload actually useful in dev mode? It seems like probably not, since there are far greater inefficiencies anyway like unminified bundles, hot-reload updates, etc.

I was actually able to reproduce it on CodeSandbox too, so there did not end up being a difference there.

Potentially relevant bug: https://bugs.webkit.org/show_bug.cgi?id=187726

@timneutkens
Copy link
Member

Interesting, so let's re-open this, I guess we could drop the preload tags in development 🤔

@timneutkens timneutkens reopened this Dec 11, 2018
@cramforce
Copy link
Contributor

link-rel-preload primes the memory cache which I believe is per connection and crossorigin="anonymous" forces the request into a different connection. The disk cache, however, (surprisingly) ignores the crossorigin-ness.

Script and link element must definitely have the same crossorigin value (or none).

@timneutkens
Copy link
Member

@cramforce so by default Next.js won't add crossorigin to both, meaning it's potentially an issue with the way safari handles it? 🤔 Basically in development the bundles all have the same url and the Cache-Control header is the following:
https://github.com/zeit/next.js/blob/canary/packages/next/server/next-dev-server.js#L130

I just noticed that for error pages we set a different Cache-Control that is more involved: https://github.com/zeit/next.js/blob/canary/packages/next-server/server/next-server.ts#L247

Potentially implementing that for dev assets would make sense 🤔

@cramforce
Copy link
Contributor

@timneutkens Maybe switch from the header to a per page-load random value as part of the URL. Would also defend against overzealous ServiceWorkers.

@exogen
Copy link
Contributor

exogen commented Dec 11, 2018

@timneutkens When I was experimenting with this I actually tried changing that exact line with all manner of caching headers including max-age, no-cache, an Age that was clearly over the max, etc. and Safari just ignored all of them, unfortunately.

@nickerlan
Copy link
Author

Looks like it started to work after I add ?date=Date.now() to page links in Next sources.

@flippidippi
Copy link

Still having this issue also. Not being able to use Safari for development is a real bummer.

@svobik7
Copy link

svobik7 commented Jan 22, 2019

I am having the same issue with my Safari.

Workaround which works for me is:
CMD+ALT+E (Safari > Develop > Empty Caches)

@endquote
Copy link

endquote commented Jan 9, 2020

I'm seeing this today with Safari 13.0.4 and Next.js 9.1.7.

@seungdols
Copy link

Due to this issue during the current service development, the layout is broken due to the issue that js is called earlier than css in the external layout module.

Could you add a next config that can turn off preloading of the js file of the head?

This is currently a problem in safari.

I'm use nextjs version 10.0.5

@balazsorban44
Copy link
Member

This issue has been automatically locked due to no recent activity. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.

@vercel vercel locked as resolved and limited conversation to collaborators Jan 28, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants