I know there are steps we can take to streamline images and Javascript, and so forth, but please note that at this time we care only about why the very same website is loading exponentially slower on Windows than on Mac and iOS.
Any thoughts and suggestions related to probable causes for the slowdown on Windows are much appreciated. The website uses the latest version of Stacks and was fully re-exported and uploaded to the web host.
If you click on one of the other pages of the website (for example, any of the product pages) you will find that they load just as slowly (or even more slowly) than the home page. Those sub-pages do not have the slider stack; in fact they are much simpler in design than the home page. But nevertheless they load extremely slowly — on Windows only!!
It’s something in the Stacks CSS file for that page: http://www.anchorsemi.com/files/stacks_page_page0.css
That file’s stats:
Chrome (non-Windows) - 2324ms (2.3seconds)
Edge Windows - 25,506ms (25.5seconds)
Thanks very much for that analysis. If it helps, below is a link to the suspect file. It’s rather cryptic to me, but hopefully someone here might be able to pick it apart!
Unfortunately, that file is the CSS for every stack on that page, and it’s over 500kb in size, with a huge part a minified source (animate.css). It would difficult for someone to tell you what is giving windows such a problem from looking at the file.
Your best bet would be the process of elimination. Start removing stuff from the page and retest on windows. You can do this with a test page.
Once you have ID the culprit that is hanging up windows then perhaps you can figure out what is choking windows.
Take a look at this post from YourHead (stacks), this is about a different problem, but go to the section called How to find the problem, and follow these steps on identifying the problem stack(s).
You have a lot going on on this page.
Page weight (bytes on the page)
35% - CSS
32% - Javascript
24% - images
Only about 7% is actual HTML, with 2/3 of the page weight being for styling and effects.
Additional testing using webpagetest.org and tools.pingdom.com indicate that data transfer time from the web server to a Windows browser is excessive. Data transfer time to an iOS or Mac browser is normal.
The timing charts, particularly on pingdom, distinguish clearly between connection time, wait time, receive time, etc. In every case, the receive time to a Windows browser is exponentially longer than to an iOS or Mac browser.
The charts I gave you above are from http://www.webpagetest.org/ if you look closely the only file that is really affected is the one I gave you above. Not sure what your ISP is going to do, webpagetest.org has nothing to do with the Internet Service Provider you’re using, you don’t even need to be on a Windows machine to test.
Don’t know or really care for pingdom, but webpagetest you choose (advanced settings), the speed, browser, and the location they run the test from. The screenshots above are run from Dulles Airport, VA and clearly show a drastic slow down on that one file. The screenshots are just the summary screens, you can get a lot more details from the test results page.
Look more closely and you’ll see that every file transferred to a Windows browser is very slow. Even JPEG and PNG files measuring 200KB are taking 5 seconds or so, whereas they take only milliseconds to transfer to an iOS or Mac browser. Our ISP might be throttling our speeds for some platforms, or there might be some other culprit on their side. This problem started suddenly, without any changes made from our side, which further lends credence to an ISP-related issue.
Again, the size of CSS files does not seem to be the problem. Every file is taking much longer to transfer than it should, and only to Windows browsers.
Your ISP (that’s who provides you your internet connection) would have nothing to do with the test results from webpagetest, they don’t use your ISP.
It could be your hosting company’s server, but not an ISP.
Sorry, I should have clarified that our corporate ISP is also our web services provider. And I was just reminded by my colleague that we have a mirror of this website running on a Chinese web hosting company at the following URL:
