Develop Reference

How to tell the browser to do the javascript manipulated webpage scaling before any content starts to show up?

I am building a website for me and I care about performance, speed, user experience and a lot more. When I started I didn't know much and I made an initial design using adobe xd. Then using webexport plugin I got a html file that has 2k+ lines of codes for scale to fit any screen and proportional resize of everything. I think I made a 1080p standard artboard but somehow it was way too big like 3554px by 2216px. So the webpage is now that big and scaling is running on it. I don't think it's too big for a browser to handle. Things were good before chrome 97 or 96 update. After that chrome and any browser running on chromium just can't scale my webpage fast enough to fit the screen. I see big divs getting smaller and it takes kinda like 500 ms to settle with decent setup. A lot of variables can affect the performance like if the machine(pc) and network is slow the scaling takes couple of seconds which is too much.
Is there any way to hint the browser to do the scaling first then make the page visible? The older version of chrome was doing it right. I can make the page visible after 600 ms using setTimeout function but doesn't seem what I want.
CSS
will-change: transform;
Tried this but it has bad effect like blurry text on my content. I don't know why it's pushing the browser to it's limit sometimes, maybe I can better optimize my page but these browsers should be more powerful (safari is the worst - can even render the webpage)
This is the home page
https://elomymelo.com/
You should see big page fitting inside the screen and it'll probable take 200 ms pretty fast
proportional resize on window also works
This is a heavy article page
https://elomymelo.com/oneplus%20nord%20review.html
I tried to hide the scaling effect in this page but not satisfied because browsers mess up sometimes. I need the javascript scaling done much faster like visitors will not see that weird transition.

overflow:hidden looks different on Firefox vs Chrome (CSS)

I have the following 2in x 1in barcode I am creating (Must be these dimensions). If the name is too long I want it to overflow:hidden. This works great in Firefox, but in Chrome it does not (See screenshots). I am guessing it has something to do with my CSS. I also verified both browsers are at default zoom.
Firefox:
Chrome:
Working demo:
http://blastohosting.com/barcode_overflow/
As you can tell in Chrome, you can see part of the words at the bottom not completely hidden.

This has to do with the rounding of the font-size.
Use an interger font-size and it will look the same in both browsers.
Ex: font-size: 13px;
EDIT: also I recommend using pixels for the dimensions, using inches may have different displays between browsers (I haven't spotted any difference but I prefer to use pixels in a pixel environment).

Chrome uses the WebKit rendering engine. Firefox uses the Gecko engine. Both interpret and display type slightly differently, as do the DirectX and Vega graphics engines used in IE9+ and Opera. You can't force browsers to render text identically.
For sub pixel problems in css
you can reset your css by http://developer.yahoo.com/yui/reset/
More information here Fonts looks different in Firefox and Chrome

Has there been a recent update to chromes webgl implementation?

I am developing a website which can be found here.
In a nutshell this is a fluid dynamics solver executing in webgl fragment shaders. The result is mapped to a textured quad and rendered on the canvas.
While doing some development work this weekend, I noticed that the Low and Medium resolution versions of the page are no longer working on Chrome (see the links in top right corner). However, if you open the page in Firefox everything works as expected. Be warned, this page is not expected to work on mac unless you've enabled webgl, it doesnt work in IE, and I havent tested it with opera.
A few other odd symptoms:
The mapping of mouse position to canvas position is now wrong in chrome unless the window is fullscreen.
The low and medium quality version appear to show only a tiny section of the low right corner of the texture.
To observe this in low/medium click the Analyze tab, and quickly change the velocity slider between low and high. Try this out in high mode to see the difference.
Last weekend the framerate in chrome was 60fps on my machine, its now 30fps even in high quality. Firefox gets a stead 60fps
The only real difference between the low, medium and high implementations is the texture resolution, which is 256x32, 512x64, 1024x128 respectively.
Can anyone shed some light on what is going on?

I'm not sure if this is the problem, but based on the simulation (and the corruption artifacts I'm seeing) it seems like you may be using floating point textures to store/render the simulation state. There was a semi-recent change in Chrome that fixed a bug in how filtered floating point textures were exposed and required some code changes. You can read about it here:
IMPORTANT: Your WebGL floating point texture usage needs to be fixed!!!!

How to improve webkit image scaling performance

On a web page, I'm scaling an <img/> tag.
To this end, I use the css3 transform scale function linked through jquery .animate method (https://github.com/louisremi/jquery.transform.js). All in all, result is good on Firefox and IE9. But under webkit browser (notably chrome 21), there's a big performance cost and the animation isn't looking good.
So, I take a look at the chrome devtool timeline. And the problem is definitly caused by the repaint of the <img/>, the time taken to repaint the image is incredibly long.
Just so you know, we don't access dom to often (never while animating), and we use requestAnimationFrame. The trouble really seems to live in the algorithm used by webkit to resize images. We added css -webkit-transform-style: preserve-3d;, this helped a bit, but not so much.
Do anyone have a hint on this ?

jquery scrollTop performance in IE 8

I'm using jQuery .scrollTop to scroll image within a div. It works great in Firefox - scrolling is very smooth and fast. In IE 8 scrolling is very slow and glitchy - image scrolls once in about a second - two seconds. Image size is on average between 2000 * 2000 and 4000 * 4000 pixels.
Is there a way to improve this for IE 8?
Performance in IE 7 is slightly better, but still not good enough.
Thank you
Edit: I believe that an issue is in how scrolling is implemented in IE 7 and 8. I have enabled both scroll bars (overflow-x and overflow-y), and I have tried scrolling an image using these scroll bars. Issue is exactly the same. I've tried running this on a fairly underpowered PC - pentium dual core few years old with 2 GB of RAM as well as Core i7 desktop with 2.8GHz CPU 1600Mhz RAM and the results are nearly identical. FireFox scrolls a lot faster, however its CPU usage on average is 10% higher than IE CPU usage. This leaves me puzzled...surely Microsoft would have addressed this issue by now?
Another thing that I have found slightly odd is that scrolling ran faster on a Core 2 Duo laptop. I'm wondering whether this has anything to do with graphics card drivers...does IE 7/8 even make a use of GPU?
Excuse me if any of this sounds silly, but I'm really interested in solving this problem...IE can't be that bad..

jQuery's .scrollTop() is notoriously slow in ie, and if the markup is even slightly complex or large, you'll never get it to perform well.
The solution is to not use the jQuery .scrollTop() function, but build your own based on the native properties .scrollHeight and .scrollTop.
The reason is the way ie computes offsets, which is the base of jquery's .scrollTop() slowness - you have to walk up the DOM tree and calculate offsets for every parent in ie.
jQuery does this the best it can, but you will always be able to do it faster since you know the markup in advance and can optimize this - you can even do the offset calculations in advance most of the time and just use a constant as modifier.
All that said, this might not be jQuery's fault - it can simply be a problem with ie's rendering pipeline - depending on how you made your marklup and styling of it, a scroll might force ie to completely rerender/repaint the page for every pixel you scroll, and that will slow it all down to a crawl.