Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Using SVG as image placeholders

medium.com

Post reply on HN
Print view View original

71–80 of 139 posts

Re: Using SVG as image placeholders

#71

Post by dopeh »

cabalamat wrote: post #58

Am I the only person who finds it ironic that a web page about keeping web pages small comes with multiple megabytes of Javascript? It doesn't need it, folks. It's a static blog page.

Couldn't agree more. If you look at what's happening in the network tab of the developer tools, you'll see it's doing a lot more than providing just a static blog page.

Instead, every x seconds it executes another POST request with pretty much all the details they can gather (scroll from top, scrollable height, referrer etc.). As soon as you start moving your cursor, the new requests start adding up very quickly, with lots of new params such as "experimentName: readers.experimentShareWidget" or "key: post.streamScrolled".

It really is collecting every single interaction with this page. As it's provided by Medium I'm sure it's part of their data collection program.

Re: Using SVG as image placeholders

#72

Post by nebulous1 »

cabalamat wrote: post #58

Am I the only person who finds it ironic that a web page about keeping web pages small comes with multiple megabytes of Javascript? It doesn't need it, folks. It's a static blog page.

It loads 500kb of javascript files, not including the two codepen docs. Also, there is actually functionality on the page, it's not just a static page.

Re: Using SVG as image placeholders

#73

Post by andreareina »

limeblack wrote: post #62
cabalamat wrote: post #58

Am I the only person who finds it ironic that a web page about keeping web pages small comes with multiple megabytes of Javascript? It doesn't need it, folks. It's a static blog page.

I'm on mobile right now and therefore it is difficult to look at source but wouldn't the JavaScript be cached in most scenarios while the images would be unique per page? On a side note I have no JavaScripts on my own blogs.

I wouldn't count on anything being in the cache, especially on mobile. Even on desktop, I've just checked my cache and any Medium resource shows exactly 1 hit. With ~350 MB in my cache (default value), it's not going to stay long before being evicted.

Re: Using SVG as image placeholders

#74

Post by flukus »

nathan_long wrote: post #9

Clever, but I'd love to see browser support for FLIF make this kind of thing irrelevant. > FLIF is lossless, but can still be used in low-bandwidth situations, since only the first part of a file is needed for a reasonable preview of the image. > A FLIF image can be loaded in different ‘variations’ from the same source file, by loading the file only partially. This makes it a very appropriate file format for responsi…

Do we need a new format? I remember jpeg's had this kind of functionality back in the days of dialup, all the patents for that should have expired long ago.

Re: Using SVG as image placeholders

#75

Post by baddox »

fogleman wrote: post #13

(Developer of Primitive here.) Love seeing people use my software in different ways! If this looks interesting to you, try it out: https://primitive.lol/ https://github.com/fogleman/primitive Also, I made a Twitter bot that posts samples every 30 minutes based on "interesting" Flickr photos using randomized Primitive settings: https://twitter.com/PrimitivePic

This looks great! I would definitely pay the $10 for an iOS version. I can see myself playing around with this on an iPad Pro for hours, especially with drawing mode.

Re: Using SVG as image placeholders

#76

Post by chrismorgan »

rocky1138 wrote: post #10
AnkhMorporkian wrote: post #5

Earlier quoted context omitted.

I disagree. If you have a user on a very slow connection on an image heavy site, the user experience will be enhanced significantly. Depending on how you implement it, you might even save them bandwidth. No interesting content for them in the current viewport and they scroll past the placeholders/go to the next page? Cancel the XHR requests you made for the full-size thumbnails/images and start anew.

I agree with GP. Personally, I hate websites that show a blurry version of an image before the final one loads. It plays with my eyes. I have to look away and peek to see if it's done before I can read on. I wish there was a way to disable this functionality.

Ditto.

It’s even worse when combined with lazy scroll-based loading: now you’re guaranteeing that I’ll see the unpleasant version briefly (especially in Australia, I imagine, where there’s generally higher latency on such requests than in the USA—but I haven’t tried Medium or similar sites from the USA, so I’m not sure if it’s as unpleasant there).

It’s worst of all when combined with lazy scroll-based loading and an unreliable internet connection: I load pages in places where I know I have an internet connection, and then read them in places where an internet connection is unavailable. With lazy loading of these things, I can no longer be confident that it’s actually loaded everything I need. Same deal with Medium’s blocked iframes for things like CodePen—that just means that the iframe is not loaded when I need it to be.

I want less magic, not more, because we’ve proven as an industry that we’re not responsible with magic, and always manage to make a mess with it.

Re: Using SVG as image placeholders

#77

Post by klodolph »

LeifCarrotson wrote: post #61
klodolph wrote: post #33

Earlier quoted context omitted.

> Are you saying that for the same bandwidth usage, you could load two separate lossy JPGs and they'd look better? The tests I've done are along the lines of this (I forget the exact numbers I used): * JPEG: 10kB + 90kB * FLIF: 100kB JPEG usually wins for photographic source material. I was unable to come up with “reasonable” parameters where FLIF would win, but perhaps someone creative can figure that part out.

You didn't mention the result of your tests, but I infer that you found the 90 kB JPEG to be superior to the 100 kB FLIF/PNG? That seems reasonable, if unfortunate.

Yes, for photographs. This shouldn't be surprising.

Note that the FLIF home page doesn't even claim that FLIF is superior to normal JPEG images... it only claims that it's superior to other lossless formats. For lossless formats, you can compare your desired metric (e.g. file size) for your corpus. For lossy formats, you can either fix subjective quality and compare size, or fix size and compare subjective quality. (Or compare some other metric, but these two are more common.)

These are completely different ways of evaluating compression algorithms, and it intuitively makes sense that different algorithms will be better if you evaluate them differently.

Consider that FLAC gives the best bitrate for lossless audio, but Opus gives a far better bitrate when you fix the subjective quality or a better quality when you fix the bitrate at reasonable rates.

Or consider that there is a wide spectrum of data compression algorithms, each of which performs the best depending on how you assign weight to compression speed, decompression speed, and compression ratio, and what is in your corpus. There is a surprising variety of new compression algorithms out there, some of which may be the best for your use case even though their compression ratios are significantly worse than other well-known algorithms (LZ4, LZFSE, Snappy, for example).

JPEG is designed for best quality at reduced bit rates, so it should not be surprising that it is good at doing that, even though it is old and newer algorithms are better.

Re: Using SVG as image placeholders

#78

Post by quakeguy »

fogleman wrote: post #13

(Developer of Primitive here.) Love seeing people use my software in different ways! If this looks interesting to you, try it out: https://primitive.lol/ https://github.com/fogleman/primitive Also, I made a Twitter bot that posts samples every 30 minutes based on "interesting" Flickr photos using randomized Primitive settings: https://twitter.com/PrimitivePic

Well, this is awesome!

Re: Using SVG as image placeholders

#79

Post by loopdoend »

IshKebab wrote: post #64

Are those SVGs actually smaller than JPEGs included using data URLs?

The only savings you get from data URLs are from less HTTP/whatever overhead. It’s like embedding the image in the source so everything gets loaded in one request. Base64 is not compression.

Re: Using SVG as image placeholders

#80

Post by kylemathews »

If you want to see this in action in Gatsby, checkout https://using-gatsby-image.gatsbyjs.org/traced-svg/

It's super easy to integrate this into your site w/ our Image component & GraphQL fragment.

See the source code for the page: https://github.com/gatsbyjs/gatsby/blob/master/examples/usin...

And component documentation https://www.gatsbyjs.org/packages/gatsby-image/

Post reply on HN