Site's responsiveness broken?

#1

Hello,

Main page of the site seems broken on mobile phones :confused:

1 Like
#2

Can confirm that the main site is loading incredibly slowly for me also.

1 Like
#3

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
#4

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
#5

@inovaekeith is working on the website at the moment, he mentioned it on Discord yesterday.

#6

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.

#7

I didn’t know a new release was going live sry

Thank you !
(Archos, Android 6.0.1 + Chrome)

#8

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
#9

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 :slight_smile:

#10

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.

#11

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
#12

Neat, but does require a build-based deployment, will definitely look into applying this for our projects that do have such setups.

1 Like
#13

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).