Heb je behalve F5 en CRTL-F5 te proberen via de instellingen je cache geleegd? Of nog grondiger: een nieuw browserprofiel (dat heet zo te zien een nieuwe
persoon in Chrome) toegevoegd en gekeken hoe je nieuwe website het dan doet? Of zelfs een nieuwe user op je pc, of vanaf een andere pc? Het punt is om te controleren hoe het gaat als je qua browser met een maagdelijk wereldje werkt in de zin dat het zelfs nooit met de oude versie van je site in aanraking is geweest. Als je dan de fouten nog ziet dan kan het niet aan Chrome liggen maar moet er iets fout zijn in je website. Dat soort tests moet je niet overslaan, voor je het weet zit je op een andere plaats te zoeken dan waar het probleem eigenlijk zit.
Als de conclusie hierna nog steeds is dat de nieuwe versie van Chrome de wijzigingen in je site niet goed oppakt het volgende.
Omdat je het niet noemt krijg ik de indruk dat je niet op de hoogte bent van wat er allemaal in het HTTP-protocol geregeld wordt op het gebied van caching. Je website bestaat niet alleen uit html, css, js en dergelijke maar ook uit hoe de webserver en webbrowsers met elkaar praten over HTTP(S) en hoe de webserver aan de browser vertelt hoe lang allerlei componenten gecachet kunnen worden. Daarmee is ook de webserver en hoe die is geconfigureerd onderdeel van je website.
Het is te lang geleden dat ik me zelf met webontwikkeling heb beziggehouden om dat allemaal nog in detail paraat te hebben of bij te zijn met de laatste ontwikkelingen, maar ik heb dingen meegemaakt die sprekend lijken op waar jij nu inzit. Zeker toen ik nog een beginneling was op dit gebied heb ik er af en toe behoorlijk mee geworsteld. Het kwam er steeds op neer dat er niets mis was met de webbrowsers maar dat mijn kennis van cachingmechanismen en vooral allerlei subtiliteiten ervan tekortschoot. En meer dan eens werd ik daarmee geconfronteerd als er een nieuwe versie van een browser was uitgekomen. Die hield zich keurig aan de HTTP-standaard, misschien juist beter dan de vorige versies, maar een net ander gedrag dat binnen een standaard past kan tot fouten leiden als je als ontwikkelaar die standaard niet helemaal zuiver had geïnterpreteerd. Hoe caching hoort te werken staat hier:
https://tools.ietf.org/html/rfc7234. Het is niet voor iedereen makkelijke kost maar het doet er wel toe.
Als het je teveel is om er een studie van te maken of als je de configuratie van de webserver niet kan beïnvloeden dan heb ik een andere suggestie: zorg dat als de inhoud van .css- en .js-files verandert je ook de namen van die files verandert, bijvoorbeeld door met versienummers te werken en die in de naam op te nemen. Dan zal een browser nooit de oude inhoud blijven hanteren omdat die een andere URL heeft en voor de browser niets met die andere URL te maken heeft. Dit betekent natuurlijk wel dat je bij elke wijziging ook alle referenties aan die files moet aanpassen. Hoe bewerkelijk dat is in jouw opzet kan ik niet beoordelen. Besef ook dat dit niet waterdicht is: als een browser besluit een gecachte, verouderde versie van een pagina te gebruiken maar een .css- of .js-file opnieuw op te halen dan gaat er iets verkeerd als die oude versie niet meer bestaat. Maar dan moet de bezoeker dat wel met een druk op F5 op kunnen lossen, als de HTML-pagina opnieuw wordt geladen komen de gewijzigde referenties mee. En je kan besluiten om gedurende een periode de vorige versie nog even laten staan zodat die er nog wel is.