Tag Archives: frontend

Programming

Slow SPAs are worse than NoSPA

I got a digital subscription to the Economist for my birthday last month so I’ve started reading a lot more content on their site. As a result I’ve noticed a lot of weirdness with their page loads that was hardly noticeable when I was using the free tier of a few articles per week.

The site seems to be built as a SPA with a page shell that loads quite quickly but takes far longer to fill with content and which has some odd layout choices and occasional pops and content shifts.

The basic navigation between the current issue index and the articles is hampered by what appears to be a slow load or render phase. Essentially it is hard to know whether the click on a link or the back button has registered.

By replacing traditional page navigation the experience is actually worse. The site would be better if the effort going into the frontend went into faster page serving.

I’m not sure if the page is meant to be doing something clever with local storage for offline use but it seems to need to be connected when browsing so I’m assuming that this is something to do with the need for a subscription and payment gateway that prevents a fast server load of content.

It still feels as if the page and the 200 words or so should be public and CDN-cached with the remaining content of the article being loaded after page-load for subscribers.

The current solution feels like someone has put a lot of effort and thought into making someone that is actually worse than a conventional webpage and that seems a shame for a site with relatively little content that is mostly updated once a week.

Standard
Web Applications, Work

Using SVG in the modern website

Using SVG when you are putting together a new website is a pretty sound decision, it’s over a decade old, well-supported by browsers and the ability to scale images accurately via CSS is pretty compelling when you are rapidly trying out different layouts and proportions.

Of course until recently IE has been the bugbear but IE9 actually has pretty decent SVG support. It is now worth thinking of using SVG as the general case and IE8 as the exception which can be switched to PNG via Javascript. The first iteration of Wazoku Idea Spotlight used SVG exclusively and the second iteration will do a Modernizer based switchout for IE8 but essentially still be SVG based.

Therefore I was pretty confused when I was taking a random check at the app in IE9. Instead of displaying alt text or the images instead there was just whitespace. Quickly opening the images revealed that IE was quite happy to render them at full window size and that there was no issue with loading them.

After some confused Googling I found out that the issue was that the previous generation of SVGs were generated straight out of Adobe Illustrator where as this set are going through Inkscape where I am tweaking the colour, size and so on. Inkscape does not allow you by default to specify a property called the viewbox. Instead this is only created if you export your file as an Optimized or Plain SVG. It is an outstanding feature when you go looking through the Inkscape bug list but it is a really obscure bug (hence this blog) to track down. The reason the images were appearing as blank is that without a viewbox IE9 crops the image to the CSS dimensions rather than scaling it. Firefox and Chrome scale it as you would expect. Essentially I was seeing the top-left 32 pixels of an image that IE9 considered to be 640px square, overflow hidden.

Having found the problem I then converted a test image to Optimized SVG, who doesn’t love Optimized things after all? Well the answer to that is Chrome. Firefox (probably due to having the longest SVG heritage) did the right thing in both cases and IE9 was fine with the Optimized version. Chrome stretched the image out on the vertical and via the Developer tools it was possible to see that the Dimensions value for the image was completely incorrect with a letterbox set of dimensions rather than a square.

In the end the thing that worked everywhere was Inkscape’s Plain SVG format. Something I am fine to live with. It would be nice to be able to set a viewbox from Inkscape’s Document Properties though and I will be keeping an eye out for it on the release notes in future.

Standard