FLIR: avoiding ugly page loads - javascript

I'm building a site that makes extensive use of FLIR to allow the use of non-websafe fonts. However, pageloads are an ugly process, as first the HTML text version of each field loads and then (a few hundred milliseconds later) it's replaced by its FLIR image counterpart.
Is there any way to avoid this sort of thing? I've got a client presentation in a few hours and I know it'll raise eyebrows. My situation is sort of related to this question which is in regards to sIFR, not FLIR. Any ideas?
Thanks,
Justin

Try putting the following rules into your stylesheet:
.flir-replaced{text-indent:-5000px;}
.flir-image{display:block;}
You may have to modify your other FLIR-related CSS rules to account for the fact that the generated images are now vertically aligned to the top of their respective parents.

It's been a while since I used FLIR, but I recall there was an internal caching method that would pull from cache on load instead of generate it each time.
http://docs.facelift.mawhorter.net/configuration:settings
Also, you can't have too many on the page at once. I found that between 6-10 were optimal for performance.
Are you on shared hosting? Is your css/js compressed? I found that the initial load was a little slow, but fairly quick after the images had been generated.

Related

All scripts AND libraries in ONE js script?

Ok so I am in the process of building my first Javascript 'framework' or 'bootstrap' which will be implemented in combination with a single pre-processed CSS file. I am gathering my favorite content slider, smooth scroller, content slideshow, parallax elements & bg-img, sticky elements, among a few more cutting edge navigational & UI based scripts (cross-browser/platform/device/viewport compatibility and performance). My problem is when constructing my demo page with all combined elements in place loaded and active on the page... well many seeem to require a different version of Jquery to be called in order to function properly. I have managed to get them to work properly while testing by carefully reordering the jquery librarys as they are called in the of the page. Now here is my (2) part question:
How do I get all my JQuery to work properly without loading multiple versions of it (one for each script almost)
I have a sample in my portfolio which I would love to use as the example. http://www.nicholasabrams.com/ (non mobile device version). In the src for that URL you will see only (1) js and (1) css - including the jquery libraries which are ALSO included in the single .js in the begining of the file. Please don't flame me, as I am asking for help. The link above works fine now (with apple as a slight exception)... but I am just trying to eliminate any bad practices I have as I have just started as a web developer at my first large company. Thanks!!
PS: Would post a snippet but its quite a large js file as you would imagine but if you will, please inspect my src and let me know what you think because my sites first load decreased from 22 seconds to 4-7 seconds after doing the above I wish I could just include the latest version of JQuery!)
if I understand you correctly you are loading more than one jQuery library to the page (in different order)? That's a mistake - you shouldn't do that.
What you should do is make sure that the plugins you work with are compatible with the library you are working with. If they're not - wither find other plugins or fix the ones you have to support the jQuery language you are using.
You have a 2 megabyte hi-res background image, that is insane! I would scrap that and the swirl image, while it may look cool to you, it is distracting and may actually make people want to avoid your website. It makes it difficult to concentrate on the text in the middle of your screen. You don't want people to remember the swirling image, but rather your portfolio, right?
You also have 404's on the following:
http://www.nicholasabrams.com/ScrollSpy_files/result-light.css
http://www.nicholasabrams.com/example-images/testing_station.png
404's are bad for several reasons, they are a wasted resource as they slow the loading of your page, because it attempts to find something and does not find it, and, finally, they have a negative impact on your SEO, specifically Google PageRank docks you for any 404's.
Find a way to work with one version of jQuery, it will eventually bite you to have multiple versions of the library and it is a bandwidth killer to have your users load up a bunch of libraries, even if they are CDN'd.

Best practice - pre-write HTML in document with display:none, or create with JS?

I am developing a large scale HTML5 app, and I really wonder about this issue. I will have a lot of dialog boxes and tabs that will open by user interaction.
I wonder what is the best practice - writing all the dialog boxes and tabs in the HTML document with display:none to all of them, or create these HTML sections on the fly with JS or jQuery every time the user making the relevant interaction.
What is better in terms of performance, ease of development, readability, etc?
Any help will be appreciated.
I'll try to address this question as good as I can.
1 - As I said in the comments, Avoid inline styling.
First and foremost this is because inline styling voilates DRY.
Having to repeat the same thing over and over again for this is very bad for maintenance and for developing since instead of changing code once you have to change it at ~100 places.
2 - Avoiding inline styling is also good for accessibility, some screen readers and search engine crawlers do indexing work and reading work based on css selectors and thusly using inline styling will force them to either ignore or misintrepret things.
3 - When working as developers it's easy to do inline styling "just for the fun" but what you're actually doing is mixing concerns. HTML is the content and CSS is the design.
Mixing these two usually leads to headaches and making my job as a developer that comes after you a pain in the effin ass since I have no idea what's styled and how.
Now, onto performance.
When you use inline styles, what you're telling the browser is basically "hey, for every page page view apply these styles to all of these elements." Now, this just became really apparent why this is bad.
You have no ability to cache and store your css and basically forces the browser to rerender your styles every time. Using an external CSS file will actually help you speed up your site since the browser caches it.
That was that for the css part.
The javascript you had asked about.
As I said, hide things with css and show with javascript. Now why do you want to do this instead of pulling everything in?
Well, you can do both. If you're only a webbrowser experience then you can do either, it doesn't matter. I myself prefer to have stuff in the DOM because it relates to content and if you're a large app having dozens of dozens of ajax calls will only make it harder for maintenance. I believe if you have to ajax stuff in make sure it counts and is logical and not just for the kicks (I think this applies if only you have jQuery and plain javascript at your disposal).
If you're working with backbone.js, for example, it's based on views and introduces some form of "MVC" into your frontend enabling you to have views with subviews that can pull content in from the server.
Hope that helps a bit with making a decision! :)
I would say it depends on how many tabs your application has and how big these are.
Big content inside the tabs mean that the application will take long to load when started and consume much ram. If this is the case, I suppose to load them as needed.
Small content inside the tabs will load fast, so load everything at once to increase performance when the tabs are clicked.
Don't forget to run some tests on older computers with a slow internet connection to see how your application behaves. Not everyone has the newest and fastest hardware.

Simple but long page is very slow in IE and quick elsewhere (long DOM causing problems?)

One of the pages served by my application is very long (about 8Mb of source HTML, mostly tables). I know this itself is a sign of wrong architecture but there are circumstances that don't allow to change that quickly :(
In almost every browser apart from IE the page is still fine - of course it's slower than an average one but it looks like the time it takes to display is mostly defined by code download speed, and I have no problems with that.
It is very different in IE (7, 8 and 9) though - the page is extremely slow for about 10-15 seconds after downloading with frozen screen effect, then experiences noticeable scrolling lags and "script is running slowly" messages while there is no javascript running on the page. IE9 takes about 800Mb of RAM as well when displaying that page.
When I serve plain text content of that size it is much better, but formatted HTML tables seem to be causing problems. It looks like long DOM is a blocker for IE of any version.
I don't know what answer am I hoping for - obviously a proper solution would be to change the page architecture by breaking it down on server side and serving piece by piece via ajax, but still - is there any kind of say magic pragma or js for IE to stop doing what it does with DOM tree speeding it up?
It would be the best solution to chuck page downloading by client. But you have to be advised that the "table" tag is the most slowest rendering tag in IE (as my experience says). So in the first step I think you should do some modifications on the HTML document. Here are some suggestions:
Clear inline style sheets and use css classes as far as you can. It will help your HTML document to be smaller in size.
use some other expressions instead of using TABLE. using DIV s would be my first recommendation. Simplify your document and the parser can read the codes as easy as you can. So make them easy to read. It causes to write less and again, it helps the document to be much smaller.
remove all the spaces, tabs, new line characters and many other extra contents from the HTML document.
Qualify the content you are presenting to be more useful for the client. As we all now, we can see two lines at most. So all the data on one page is not a good idea, actually useless. Because while user is downloading the document, some data might be updated on the server and the data your user has is not valid anymore.
After all, always remember that every character stores 8 bytes in the memory (no matter it's virtual or not) including all the parsing variables and memory uses by xml parsers and some how hard codes to load the HTML string and make a DOM out of it. The speed to read the document and parsing it is so important as much as the size would be.
Hope it helps you..
Cheers

Maintain height of the website

I have a client who wants to do a website with specific height for the content part.
The Question:
Is there any way that when the text is long / reach the maximum height of the content part, then a new page is created for the next text.
Within my knowledge, somehow I know this can't be done.
Thanks for helping guys!
You will probably want to look into something like jQuery paging with tabs
http://code.google.com/p/jquery-ui-tabs-paging/
Unfortunately you would need to figure out the maximum number of characters you want to allow in the content pane and anything after that would need to be put into another tab. You can hide the tab and use just a link instead.
Without more knowledge on what you're development is, this is a difficult question to answer. Are you looking to create a different page entirely, or just different sections on a page?
The former can be done using server-side code (e.g. Rails), and dynamically serving out pages (e.g. Google results are split across many page).
The latter can be done with Javascript and/or CSS. A simple example is:
<div id="the_content" style="overflow:hidden;width:200px;height:100px">
Some really long text...
</div>
This would create a "scroll" bar and just not disrupt the flow of the page. In Javascript (e.g. JQuery), you'll be able to split the content into "tabs".
Does this help?
(Almost) everything is possible, but your intuitions are right in that this can't be done easily or in a way that makes any sense.
If I were in your position, I would go up to the client and present advantages and disadvantages to breaking it up. Advantages include the fact that you'd be able to avoid long pages and that with some solutions to this problem, the page will load faster. Disadvantages include the increased effort (i.e., billable hours) it would take to accomplish this, the lack of precedent for it resulting in users being confused, and losses to SEO (you're splitting keywords amongst n pages).
This way, you're not shooting down the client's idea, and in the likely case the client retreats from his position, he will go away thinking that he's just made a smart choice by himself and everyone goes away happy.
If you're intent on splitting it up into pages, you can do it on the backend by either literally structuring your content into pages or applying some rule (e.g., cut a page off at the first whole paragraph after 1000 characters) to paginate the results. On the frontend, you could use hashtags to allow Javascript to paginate the results. You could even write an extensible library that "paginates" any text node. In fact, I wouldn't be surprised if one didn't exist already.

Javascript widget implementation

I have a question about Javascript widgets. The widget I am working on simply embeds content on a page instead of using iframes. So far it looks good. But there are cases where some users layouts are messing up the widget. For example, the widget might require a width of 300px to appear. But the parent div is set to 250px and hence the right part of the widget is cut off.
I was wondering what sort of precautions should be taken to prevent this? I was talking to the product manager who mentioned he wanted me to check the parent div elements and get the size and then show an alternate message if their size is not accurate. But again, since this is Javascript and the widget is supported in many diff browsers(including IE6), I am wondering how fail-safe this method would be? What if I need to iterate the DOM all the way up before getting a valid size? I am also worried about performance here. This extra checks would slow down the delivery of my widget content to "good users" since I am adding a layer of complexity to all users. I don't want to penalize good users just because of the few errant ones.
I am not using any sort of JS library here, so any solution should not suggest the use of one. Also, the reason for not using a library was simply not to add extra weight to the page load to deliver a widget. I understand that "jquery" for example is small, but in my case, even 24k compressed seems like an overkill for a widget delivery that contains no core code for the widget.
Has anyone dealt with such issues before? What are your solutions to these?
There are reliable ways of determining the size of an element using JavaScript. You're quite right that you may need to iterate up the tree in some cases, but the answer you get will ultimately be quite valid.
Although you don't want to directly include any library code in this project, you may consider looking at how the major libraries implement their "what's the width of this element" functions to drive your own implementation.
Beware of quirks mode too.
I'd check to see of the page has Jquery, if not load it into the page using no-conflict mode. Then use jQuery to examine the page.
See: How to embed Javascript widget that depends on jQuery into an unknown environment

Categories