Hello,
Main page of the site seems broken on mobile phones 
1 Like
Can confirm that the main site is loading incredibly slowly for me also.
1 Like
I think thereâs stuff worked on it at the moment. The logo looks weird on my end. I see itâs a svg. It isnât rendered correctly on Vivaldi (Chromium Based). It was rendered correctly a few weeks ago.
Also the top bar is black at first and then blue. Better than the âinfinitybattlescape.comâ site that really should have default black background because it takes like 5 seconds to load the background image.
2 Likes
The problem of the battlescape page is both a lack of a default black background value and the fact that the background image is a 5 MEGABYTE png.
That background should at most be like a 250kb jpeg with those fancy diagonal lines added as a 10x10 tiled png overlay.
Also the concept art thumbnails on that page are not actually thumbnails they are full-size images displayed at a very small size. It all ads up to ~ 170 megabytes of ram usage for a mostly static page and incredibly long load times.
3 Likes
Yeah Iâm doing work on the website. @kamui which phone/browser are you using? I have no issues with the site on my iPhone using Safari, Chrome, and Firefox. Your problem may be that your cache needs to be cleared. On Windows Chrome shift + reload should fix this, I donât know what it is off the top of my head for other browsers/phones.
The website will likely be jacked up for people whoâve already visited it until their caches expire - I donât know how long that will take.
PLEASE version your CSS/JS itâs the first thing you learn when you start web dev at an actual company. Add a version number to all your scripts/styles and the moment you update them bump that number up. It automatically invalidates browser cache on all devices and you avoid these kinds of problems.
Example, this is what you have:
< link href="/Content/Battlescape/css/style2.css" rel=âstylesheetâ>
This is what you should do instead:
< link href="/Content/Battlescape/css/style2.css?ver=1.0.1" rel=âstylesheetâ>
How that particular number gets there is up to you but if you bump that number to say 1.0.2 or 1.0.1a the browser sees it as a new url, drops the old cached css and loads the new one.
2 Likes
I work with web devs and they didnât know it (or didnât find it cause it sounds pretty logical in fact)! Good to know thanks 
I didnât know and I doubt Keith knows. FYI the website frontend (css/html) was done years ago (pre Kickstarter) by a hired pro web designer, not by Keith himself, IIRC.
Wasnât it Keithâs sister?
Anyway, best practice is to have the cache buster in the file name not a query param because some proxies and browsers donât cache responses with query params at all.
I donât know what your deployment pipeline is like but you should be able to have your build script set the filenames. You can use a version number but I recommend using a hash of the file contents. eg Layout2.84c32944c6f06c5a143c63a203e75534c4451f8a.css
If you care about how long it is (you shouldnât really) you can always truncate the hash a bit⌠Layout2.84c32944c6.css
Hashing has the advantage of an update that just touches a few files not cache-busting all of your assets.
3 Likes
Neat, but does require a build-based deployment, will definitely look into applying this for our projects that do have such setups.
1 Like
Regardless of your deployment method, you could always run a simple script that renames the files and either writes the file names to config (that is then used by server side script when outputting the HTML) or does a find and replace (on any static HTML).