Ok so I'm writing a failry complex ASP.NET page that has quite a bit of javascript related to it. The problem is the page has alot going on with it but the browser just acts unresponsive alot of the time and lags while the javascript seems to perform fine.
In this page, I send down a array list of available items for the user to select from. Well when this list grows to like a 1000+ items in the list the page just sucks for lack of better words. If i don't have that many items to select from the page acts fine. I mean the javascript performance is ok but the page just lags. The scroll bars on the page are just laggy, it just feels like horrible. Of course none of this happens in Chrome or Firefox.
To kind of give you a little more perspective on the issue, the site has about 150k unminified uncompress css styles for this page, about 10,000 lines of code for js including frameworks, controls, and business rules specific for the page, and the array object text saved to a text document is about 200kb.
Any help on the matter would be greatly appeciated as this is about my 5th month stab at getting this faster...
One of the Yahoo performance rules is "Reduce the number of DOM elements". They say this for a reason.
When you start to go into the range of "thousands" of DOM elements, IE bogs down pretty rapidly. Every interaction with the page becomes slow. The only "solution" is to use fewer DOM elements.
For example, I recently made a web app containing 4 grids with 100 rows each with around 10 columns, all visible at the same time. Those 4000 cells were making IE really slow. I solved this by using a buffered view grid, that only renders the visible rows, and removes the rows outside of the visible scroll area from the DOM (using the ExtJS grid if it interests you).
Of course none of this happens in Chrome or Firefox.
The bane of my little web app developer existence once things get awesome. There's no answer usually other than to simplify the page.
The concepts behind pagination apply to other application pieces. Active Directory won't display every record in a single list once it's large--and it's a desktop app.
Cut it back and then use the interface to get things gradually (usually through JSON requests for me).
Related
I have a single page using CSS columns that reflows on load.
Even when I remove all IMGs and iFrames, so it is fetching no
external resources, it reflows.
I can't figure out what is causing the reflow/repaint. Any CSS exports
out there able to figure this one out?
https://github.com/treenotation/dumbdown/issues/8
There's too much content in document.
The browser will gradually display the content, that is, the content involved in rendering will gradually increase, which affects the layout calculation.
You can add the "loading state" style. When window.onload Event trigger, change the style to "load complete".
Or 'Masonry Layout'.
Reason for the reflow is: a huge amount of content but NO strategy to handle with. Indeed there are many things you can avoid/do/change ...
REASON WHY - just to base the answer ...
The reflow is caused by the mechanic: at first the text (html code) has been downloaded and rendered. But there are still a lot of elements (most over images but youtube videos and iframes as well) which are still on download. As the browser don't know the size of that elements he does not keep the place for that elements.
Now: after the download and rendering of every element has finished the browser injects the element to the content and all off the following content is pushed down and in your case to next column ... reflow.
STRATEGY: MULTIPLE ACTIONS
To your question: there is not only one reason which causes multiple and long downloads. So far there is no simple single answer and even NOT A SINGLE SOLUTION. Your needed strategy will be to optimize the page by a multiple bundle of actions. But I believe doing that you can reduce it to an acceptable amount ... and maybe there is a chance.
THINGS YOU CAN DO
1. Change layout
If you change the layout to an actual web technique. That means don't use columns (flowing left to right) to a style which prepares the pageflow from up to down. Than you can asynchron load the needed elements when the user scrolls down. The technique is named Infinite scrolling: How to do an infinite scroll in plain Javascript
But I assume as the special layout has charm this won't be an option for you!?
2. Images which are not shown - remove not needed elements from download
On your page I found images which are downloaded but which are not shown on the page. (Example: 3.png with INCREDIBILE USELESS 659KB). Remove such elements from your content.
3. Reduce not needed size of elements
Additional a lot of shown images on your page have an incredibly large file size which is not needed.
Example: devices.png
image-size: 692x285px - real size
layout-size: 287x118px - needed size
file-size-download: 110kb
file-size-needed: 4kb - if (lossless) optimized
And think about: many little file downloads add up to a big amount ... and you have a lot of downloads! If you calculate: 10 images your way: 1.1 MB can be done with 40KBs
Additional:
if you you need higher solutions use srcset attributes ...
sometimes that is a practical problem with the knowledge of the editors: than teach them how to lossless reduce images and advise them the sizes to use for the images in the layout
4. Use faster server for images
It seems the download rate from your server is not the fastest one. That's normal by most providers. As you have a lot of images ... think about to load images from a faster server - if possible. Example: the pure download service from AWS (Amazon Web Service) is incredibly fast. As you just need a bucket for downloading that is not as expensive ... try it out.
5. Use placeholders for elements
As you have a lot of elements I think you maybe cannot avoid the later injection which causes the reflow. But you can use placeholders for your element so the needed place is reserved and the reflow still does not happen for this element.
Just define the html structure and possible sizes in your layout. That additional helps the editors as they know what image size they can use. Then size the placeholders with CSS and initiate an ajax image download by JS.
In case of later download now the users maybe see a placeholder at the beginning but no reflow. You can do that with few lines of code. I attach an example at the end of the posting.
NOTE: You can do this with (youtube-)videos or iframes in a similar way ;-)
6. Use vanilla instead of jQuery
As I saw has the download of jQuery an incredible impact to your download time. Really. (That's the reason why I assume your server is a slower one.) Have a look to the download time of your elements. It is one of the elements which needs the most times and blocks your elements from rendering.
jQuery is an old dog. Modern web techniques use vanilla JS ... and as I see there are no complicated things on your page you cannot realize in vanilla. So the recommendation is to remove it from you page (if possible) and you will earn a huge speed advantage.
7. Use CDNs for download when possible
Downloading frameworks and fonts from own server makes pages slow and blocks time for the page download of other elements. Use a CDN instead.
As I have seen your fonts are loaded from a CDN? But jQuery still comes from your server. If you don't want to change to vanilla chose to load it from CDN.
8. Check if Youtube can be loaded more simple
Youtube is loaded by several actions to your page. In this case I AM NOT SURE as I still did not work with youtube for a longer time. But I believe (not sure if I am right) that there is a more direct way to include youtube videos to a page. Maybe you would like to check it.
But nevertheless: work with placeholders for the video players as well. That are almost just few additional lines off css.
9. Optimizing user experience: thinking about a preloader
Reflow is not new phenomenon to webpages. Up to now a lot of pages uses preloaders to generate a better user experience. Today's technique is ajax load...
I don't know if the described techniques will avoid the reflow completely. As there are many elements the download time cannot be set to zero. But optimizing the page will reduce it dramatically. If there still remains a little bit ... maybe you like to think about the older technique. Using a nice and maybe well designed preloader symbol indeed can upgrade the user experience. Maybe on mobile views with medium data speed there is no other chance...?
But that is just to think about an additional possibility ...
[update]
10. Combine placeholder with infinite scroll
If you are using placeholders you can/should combine it with technique infinite scroll.
Means: all media (particularly images but maybe videos and iframes as well) are prepositioned by sized placeholders. That works immediately so there should be no more reflow as needed. Then load media assynchron by AJAX based on their position on their screen. Images which are in view are loaded immediately.
As you don't have so many media elements on starting viewport (most are still below the screen view) that should work as if it is a page with a 'normal number' of pictures/medias.
All others are loading afterwards when scrolling the page the media comes in view like on a 'infinite scroll page'. (Note: that works if the file size off the images is not to large, - so optimizing the images has still to be done.)
That has the additional advantage that thake makes sure that the images are loaded in the sequence they are needed ... which safes a lot of time.
Could be done in javascript:
Place images/media by placeholder technique
On window.onload check which images/media are in the viewport. Don't forget images which are only partly seen.
On window.onscroll check if image(s) comes to viewport and load image
Note: I am not quite sure if there are anchor links on your page to the single articles. I believe not. But if you still use them the starting viewport can be anywhere on the page when the user call an article. In that case window.onscroll has not only to work scrolling down but scrolling up to.
I am not quite sure if there is a ready script avaiable. But I would wonder if not. Otherwise it would not be to tricky to do that on your own. That would have the charm that such scripts mostly have less and cleaner code than preworked scripts ...
[end update]
... ... ...
I am not quite sure if the described issues are complete. Mostly there are found more possibilities to optimize a page when you start with the process. But as I had a nearer look to your page that are the most important chances.
EXAMPLE LAZY IMAGE LOAD WITH PLACEHOLDER EFFECT
Just EASY AND SIMPLIFIED example for lazy image load. Please adapt to your need.
// new html for image
<img class="placeholder-size" src="path/placeholder.jpg" data-lazy-url="https://url-to-your/imag.png" alt="Image Description">
// css
.placeholder-size {
width: 200px;
height: 100px;
}
// js for lazy load
// older code but works, please actualize if needed
window.onload = function(){
var lazyImages = document.querySelectorAll('[data-lazy-url]');
for (var i in lazyImages) if (lazyImages.hasOwnProperty(i)) {
var imgUrl = lazyImages[i].getAttribute('data-lazy-url');
lazyImages[i].src=imgUrl;
};
};
I'm enhancing the UI for an application to be more compatible with screen readers. The problem is I keep running into issues and I'm beginning to suspect that it' due to the screen reader itself.
Right now I'm mostly testing JAWS 15 with IE 8 (due to corporate limitations it's basically all I can test with at the moment) and getting some weird behavior, but as near as I can tell the aria markup and html all look correct.
For instance:
In some hidden divs (role="alert") the JAWS does not speak "button" after reading a button's name after the DIV is show. (It does speak "button" once you tab to the button though.)
JAWS is speaking elements with aria-hidden="true," which was fixed according to this thread.
Again with hidden alert divs, in some cases JAWS will repeatedly speak elements. In at least one case it will repeat the header and the first line of text infinitely (or at least until my patience ran out.)
The altText for images in table is not read when the entire page is first read. It does get read when the user navigates through the table with the table commands though. I don't even know what corret behavior is on this one...
I'm basically looking for something where I can find out if these are known issues with JAWS/IE8. And if there's a list of compatibility out there (similar to the HTML5 compatibility list) I'll be able to refer to it whenever people bring these issues up.
http://html5accessibility.com/ is a starting point to discover whether a browser has accessibility support for native elements and attributes.
If you're looking for documentation of screen reader support for ARIA attributes, check out The Paciello Group. For example, Steve Faulkner published a post on role=alert that may be helpful.
I'm writing my pixel-perfect jquery plugin to align menu items in a brick-wall way and I'm struggling with text rendering engine differences that render a given string with different widths between Chrome and IE/FF. This pushes me to search for various css techniques and tricks (such as text-rendering, -webkit-font-kerning) and I still have... inconsistent results.
The key of the randomness is that after a longer time of page inactivity (during which I search the web), refreshing it renders the text as expected, then - the subsequent refreshes, but in a close succession, render the text a bit wider, which lays out the menu in a different way, taking 3 rows instead of 2.
This occurs both when I use Google Fonts and system Arial.
The algorithm is done and working OK, so my question is not about fixing javascript or css, rather about how I could prevent the randomness from occurring. Is there any <meta> tag that I could use to get consistent results, or something?
Currently, I'm investigating several tips/recommendations for improving the performance of web sites. So, I've started with Steve Souders' excellent books (High performance web sites and even faster web sites), but I've got a couple of questions regarding some of the rules that are presented. FOr instance, chapter 5 of High performance web sites say that CSS stylesheets should be put at the top of the page because putting them at the bottom stops the progressive rendering that is performed by the browsers. According to Steve, some browsers (most notably IE) do get stuck with it and show a blank page instead of showing the items progressively. Here's the url for that test page:
http://stevesouders.com/hpws/css-bottom.php
Now, I do understand that we're talking about a book with a couple of years and that browsers (including IE) have been updated and improved. The reason I'm asking this is because I can't reproduce the behavior he mentions with any current version of FF, Chrome or IE.
Well, the thing is that Yahoo (http://developer.yahoo.com/performance/rules.html#css_top) and google (https://developers.google.com/speed/docs/best-practices/rendering#PutCSSInHead) still say that.
So, what I'd like to know is if browsers have evolved in this area and this is only problematic for, say IE 8? If that is the case, why haven't yahoo and google updated their recommendations? (btw, I've tried simulating IE7 from within IE11 and still don't see the expected result that is described in the book...)
*UDPATE*One more final note: I've decided to reproduce Steve's cgi script in asp.net and I've created a simple generic handler that does the same thing as the sleep.cgi script. what I'm seeing here is that putting a stylesheet reference (which takes some time to load - I've went with 10 seconds) inside the head ends up producing the blank page problem that is reported in the book. If you put at the end, the browser ends up rendering everything and making a second pass for applying the styles after they have been loaded. In my opinion, this makes sense because when you put the style in the header element, the browser is holding up until it gets the styles before rendering (notice that the other referenced components are still being downloaded on the background, but they're not being shown in the screen). On the other hand, when they're at the bottom, the browser will simply apply the current styles until it gets stuck in the stylesheet. WHen that happens, it will only show the html it has loaded until the stylesheet (if there are any images below it, the browser will still download them but it will only render them after the styles have been loaded).
So, after these tests, I'm starting to think that 1.) I'm missing something here or 2.) yahoo and google recommendations are no longer valid today.
Thoughts?
Thanks guys!
Simply inserting a <link> tag in the footer is not the way to defer stylesheets. The currently accepted method is to attach it using javascript:
<script>
function loadStyleSheet(e){if(document.createStyleSheet)try{document.createStyleSheet(e)}catch(t){}else{var l;l=document.createElement("link"),l.rel="stylesheet",l.type="text/css",l.media="all",l.href=e,document.getElementsByTagName("head")[0].appendChild(l)}}loadStyleSheet("/your/stylesheet.css");
</script>
Optimizing your page for speed involves determining what CSS is above the fold, inlining that part in the header, and loading the main stylesheet later using the above method.
I recommend doing some searches for "above the fold css" and check out Google Pagespeed Insights.
https://developers.google.com/speed/pagespeed/insights/
A mobile web site project I've been working on has been recently been analyzed by a performance consulting firm and they came back recommending that we move all of our .css file links to the BOTTOM of the HTML to accommodate issues on the iPhone where .css files can block concurrent server requests.
I've always known this to be true on most browsers when it comes to .js files--hence the common practice of putting .js file links at the bottom of one's HTML--but I've never heard this about .css files.
I have yet to get a response from the consulting firm with cited references as to this being an actual issue on Mobile Safari. Has anyone else heard of this and, if so, know of any specific references that talk about it (perhaps from Apple directly?)
This is not intended to be an answer to your question, but as a reference:
Best Practices for Speeding Up Your Web Site from Yahoo:
Put Stylesheets at the Top
While researching performance at Yahoo!, we discovered that moving
stylesheets to the document HEAD makes pages appear to be loading
faster. This is because putting stylesheets in the HEAD allows the
page to render progressively.
Their recommendation to move CSS to the bottom is unusual - would appreciate it if you could share why they found this to be a good idea.
edit: Looking at the general guidelines on apple.com, I couldn't find any particular reference to CSS inclusion applicable only to Mobile Safari. The basic, general instructions still state that you should place CSS in the <head>. See this page.
If you load up the following URL (http://waynepan.com/s/con/) on your desktop and then your mobile browser you'll observe a curious behaviour; On a desktop browser (Chrome & Firefox at least) you'll see the boxes populating from top left to bottom right (in the same order as on the source code) and on a mobile device (iPhone, iPad at least) you'll see the exact opposite occurring.
Albeit undocumented, this observation would suggest that the mobile browser reads the main html file first and then proceeds to render the page bottom-to-top thus loading latter hrefs first and working it's way up to the top.
You'll also observe that on the desktop browser up to 6 boxes are populated concurrently and on the mobile browser up to 4 are populated - this accounts for the maximum concurrent connections that are allowed by the browser in question to any one host.
Therefore, if page load and render speed is especially important in your mobile web app, take special care to order the loading of elements accordingly. I think your consultancy firm colleagues had observed a similar behaviour and wanted to force the CSS to load before all the other content - it would all render with the correct styles from the outset, giving the illusion (or user experience) that the page loads faster.
Alas, my 1 cents worth - I hope it is food for thought. :-)