fileserver: optimize browse template to avoid SVG icon duplication

[glowinthedark]

Description

Multiple file entries of the same type inline the entire SVG icon content which results in the same SVG icons being rendered in HTML multiple times which increases file size.

1. The PR reduces the size of generated HTML by using SVG xrefs instead of inlining
2. Minor ui fix: in search field use <input type="search"> instead of text
3. Add folder-symlink icon, as current master displays folder symlinks as file symlinks.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

---

glowinthedark seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[francislavoie]

Good idea!

This does have one downside though that for very small directories, it'll ship every SVG even if there's only one that might be used.

Your approach is certainly better for huge directories, but it's a bit worse for small directories.

The absolute-best option would be to only add the SVG ref if there's a relevant file included (and only include it once) but I'm not sure if we have sufficient template tooling to make that easy to do 🤔

Maybe we could loop through the directory listing once in Go code to collect a list of unique extensions (or a map[string]bool to allow O(1) lookups), and then pass that to the template and wrap each SVG ref with a simple if extensions contains 'ext' or w/e (pseudocode).

[glowinthedark]

@francislavoie: indeed, I didn't consider that the way it works now it will only pull the extensions that are used, yet it all probably comes down to estimating the cost: the unminified SVG for all icons takes up 14KB, and when minified it's 8.8KB — this is cheap, although accounting is always hard. )) I didn't check how many files would need to be in a directory in order to generate a bigger file size by rendering the same icons repeatedly.

[glowinthedark]

Out of curiosity generated some stats:

Number of files	Master branch	this PR
10	33 KB	45 KB
20	44 KB	53 KB
50	75 KB	78 KB
100	127 KB	116 KB
500	546 KB	436 KB
1000	1046 KB	861 KB

All files were generated of .txt type with this bash script

mkdir dir{10,20,50,100,500,1000}
touch dir10/{1..10}.txt
touch dir20/{1..20}.txt
touch dir50/{1..50}.txt
touch dir100/{1..100}.txt
touch dir500/{1..500}.txt
touch dir1000/{1..1000}.txt

With up to 50 files the master version is more efficient, and the optimization will only make sense with folders with over 100 items. Do you think it is worth optimizing? I am in two minds..

I would rather revert to the current approach in master and just add the folder-symlink icon which is currently missing. wdyt?

[francislavoie]

Thanks for those stats! Very useful.

Also worth checking is gzipped size (if you didn't already). I think repeated SVG will compress very well.

But it's true that linked SVG will probably perform better in the browser (refs instead of copies) though that's also a micro optimization.

I agree I lean towards master, unless you're interested in going the extra mile with my suggestion of only shipping SVG for extensions seen.