Zers becoming more sticky

Ref: The label for my browser app container on my devices is “zerz” (short for browsers if you are still mystified). It’s sort of stuck with me.

“Which zer are you using?” Pops out of my mouth unconsciously these days.

“Have you tried the Vivaldi zer yet?” Things like that.

Forthwith: Are Zers Becoming More Sticky? Short ans: Oh, Yes.

Icon Bay on my tablet.

Website stickiness refers to how long a guest hangs out on a site or sometimes how many hits a site accrues over a certain time period. A website is oh-so-sticky if people do none other than stick around rather than surf fast away.

What I’m referring to is zer (browser if you haven’t caught on yet) stickiness, which for me means how much a browser recycles objects stored in its cache. I’m noticing a change notably in Safari (the grand master of browser stickiness) and the ever more ubiquitous Chrome, with Google/Alphabet following Apple’s lead once again.

File hierarchy often goes on the order of:

Typical file/dir hierarchy.

Devvers link their webpage code to libraries of further code where repositories of Javascript or CSS style sheets (or CGI or Perl or PHP or Ruby, ad. naus…) reside and are imported by the zer’s Document Object Model by links configured in the HTML code and then run asynchronously as part and parcel of the gestalt codebase.

This has been the model of software development from time out o’ mind.

(Fairy coachmakers and all).

But I’m starting to add changes I might make to scripts or styles directly into the .html page so that I can actually see the rendered updates stat. Changes made to the library file are increasingly not being read when refreshing a live site.

And that’s what I mean by zer stickiness. I change a style, I make a code change in js and upon live site refresh, an unexpected behavior: Hey Presto. Nothing Changes!

With Safari and now Chrome, I have to open the updated library file


in a new window/tab and refresh for every change I’ve made, then get the HTML page back in focus and refresh to see the changes.

Zer producers are in a war for fastest rendering, and clearly one way they are doing this is storing more and more data, code and images in the zer cache.

Chrome at least re-renders upon closing and reopening. Safari has gotten so stubbornly sticky that even restarting the desktop system might not clear the cache. Seriously.

For images, this has resulted in changing my naming convention; e.g., on Puppy Mill Free.US, I have a number of images that update every time a new puppy store ban has passed (342 of them, to date). Instead of replacing


like I’ve been doing for years, so that other sites and interested parties can directly view or repost the latest and greatest graphic, I’ve had to add a counter to the filename and update the code pointer each time to get the zer to refresh it:


Not long ago I didn’t have to do that. I’d update the file, the server would be touched and eh, voila! the new image would be displayed.

For code-base changes in link-related libraries, I’m placing the code block directly into the HTML file instead of the link, including adding new classes in the html page <style></style> blocks as well.

This change in work flow discipline works every time and saves me the same, that is time. One refresh instead of two and a page swap in between.

The seconds, they count.

But now the rub is how to have a static URI contain the latest image. No solution yet as I don’t know how to use a referrer like the

<meta http-equiv="refresh"

for an HTML page where I can re-route the page.

Still thinking through how to do it, without having to post the image twice with 2 names.

Author: Brooks Rogers

Programming for a long time now. Working with Stencil these days and creating custom HTML elements/web components.

Leave a Reply

Your email address will not be published. Required fields are marked *