I run a PHP based landing page with a big header graphic and a div with the common JavaScript sharing buttons like Twitter, Stumpleupon and Facebook below. These buttons are slowing down the loading process for everthing that's below.
So I'ld like that the important parts of the website show up first and the less important parts should get loaded at the end.
How to archive that?
Thanks
Michael
The simplest way is to move all the JavaScript code to the bottom of the document. It may require some modification (i.e. use DOM functions instead of document.write) or restyling, but will make the site usable before these gadgets are fully loaded. Setting the async and defer is an elegant, but also complicated, alternative.
Concatenating multiple JavaScript documents helps, too, especially with older browsers with a low number of concurrent connections. You can also combine graphics(mostly icons/logos etc) with CSS sprites. On the cutting edge, data: URLs allow embedding images into the source of the HTML document. Read more about these techniques in the Yahoo Best Practices.
Additional speedup can be gained by gzipping HTML and CSS documents. JavaScript files can be compressed too, but minification (for example with the YUI compressor) tends to achieve even greater gains. You should also specify caching directives for static resources.
On the server side, you should really be using a php bytecode cacher like APC. Google has some additional tips on php best practices.
General resources:
Google: Let's make the web faster
Yahoo: Best Practices for Speeding Up Your Web Site
Great question, and one which better authors than I have written mountains about. In fact, give this article by Yahoo! staff a shot - it's the definitive document on the subject, and pretty easy to follow:
http://developer.yahoo.com/performance/rules.html
Another answer suggests moving your Javascript to the bottom of the page. This is likely to help, but won't solve all your problems and won't do much to help your images load. From Yahoo!'s guide, you would do well trading numerous smaller images for single images contained in a CSS spritesheet to cut down on HTTP request overhead, and make sure to enable caching for all your content.
You can also (advanced!) do clever, tricky stuff like only putting the important stuff in the document at all, and having javascript (located at the bottom of the page) dynamically load in the "extras" using AJAX after the initial load is complete. Spiffy!
Like others are saying you need to put javascript at the bottom. Maybe headjs library makes this task a little bit easier for you?
Related
What are the benefits of using a CSS external stylesheet over a php file set to content-type: text/css? If you place this header at the top of a PHP file I feel like you have so much more potential:
<?php
header("Content-type: text/css");
if($query_string = "contact_us") {
#nav {}
}
?>
(^ that's a .php file). http://shapeshed.com/using_php_to_enhance_css/
If there are no downfalls (and I checked how they were cached in Chrome's Network Panel and I believe it's the same), isn't it kind of like whether to use .html or .php?
Thanks for any feedback.
Here are some differences:
PHP will create extra CPU / memory overhead compared with serving purely static CSS. Probably not all that much, but still a consideration. The more processing you do the bigger a deal it is, obviously.
You can't push PHP files to a CDN
SASS and LESS have been developed to deal with any dynamic features you might need so PHP isn't likely necessary
Sounds like you're worried about serving more CSS than is needed for certain pages. Realistically it's not an issue since browsers will cache the CSS after the first download.
Additional thoughts:
I wrote a UI template engine that isolates both JS and CSS code to only the specific views on which they are used. If a CSS or JS is used more than once, it is pushed to the "kitchen sink level" and included globally. This limits selector conflicts and also best balances the number of HTTP requests and total download size per request. Also keeping relevant code (i.e. button event listeners or page / element-specific styles) close together helps with more rapid programming, especially for non-expert teams / developers.
That could have been nice before CSS preprocessors such as SASS or LESS.
Dynamic CSS isn't even as useful as dynamic JavaScript, much less dynamic HTML. Having one large file with all the rules in it is more effective than having a file with rules that change since you can more easily cache the former in the client than the latter.
The reality is that there isn't much benefit to this...dynamic CSS doesn't have many valid use-cases, and the one you're describing certainly isn't one of them. If you just combine and minify all of your css into a single file, it'll cache on the client and be downloaded only when you bust the cache it.
In a modular CMS, this could be useful. As long as your application could generate a .php URL that consistently generates the exact same CSS for caching purposes, you could dramatically reduce the amount of CSS to download. For example, pages that uses 1 theme and 5 modules (each providing CSS) could return the CSS for that combination, instead of the CSS for 1 theme and 50 modules. That could be the difference between 50KB of CSS and 500KB -- a huge savings for slower connections.
If your website is hand-made, as in a website that has specific goals known ahead of time, then there's really not a good reason to do this as others have answered.
I'm considering creating all the reports of a series of desktop business apps directly to html. Most of the reports are tables (maybe compound reports), headers, footers, etc. (no images, vector graphics, etc.).
After a search in SO, I've read lots of post regarding problems with page breaks and things like that (I don't need pixel positioning at all, but yes control at page breaks).
For example, let's say I have a big table with currency values and I need the last row of the table per page to display the running totals at that point.. it is something feasible to do easily or I will run in lots of trouble?
What technologies can help me here?
HTML5
Javascript
CSS
PHP Librarys
JQuery
Some notes:
The html will be displayed with the chrome or firefox engine embeded, so the diferences between browsers it's not a problem for me.
I can have the php preprocessor embedded if that helps to generate more easily the reports, I'm just looking fot the best technology at hand to make the work well..
I'm tired of report generators with "WYSIWYG" designers (Crystal Report, FastReport, ReportBuilder, etc.)
Thanks!
We made the exact move you're thinking about almost a year ago and haven't looked back. Most communication with our client is over the web, so it's been a perfect fit. They can view html outputs easily on our website, and can generate pdf's of the page (server side) whenever necessary. The program we use for pdf conversion is a free, easy-to-use, open-source project called wkhtmltopdf.
Where we are is great, but getting here was difficult.
Deciding which pdf engine to use was a long, painful process. The short of it is that HTML is for viewing pages on the internet, not for viewing pages on paper. Page-breaks will be the bane of your existence in this game -- you literally have to measure each page and create your own clean-looking breaks for every single report (otherwise, all html-to-pdf converters out there will just keep rendering the document onto the next page as it if encountered no page-break at all). Further complicating the matter is that every html-to-pdf engine out there handles this sh*t differently and you'll have to write a tailored solution to test each one to see if it meets your individual needs.
Now, the good news:
You can save yourself a lot of trouble by heeding my advice and going with wkhtmltopdf for your finalized reporting outputs. This little program is simply amazing -- it uses a webkit engine, renders CSS/javascript accurately, has header/footer control, optionally creates a table-of-contents page, and (most importantly) consistently produces excellent looking pdf's without having to customize your code base. It also has a variety of great command line switches, and it is very, very fast. I say again: it is very, very fast.
Best of all, it's a command line tool that can be used in batch processing. And did I mention that it's really, really fast?
Browser support for printing is generally terrible. However, there are other tools, notably Prince (which is not free) and Flying Saucer (which is free) that can generate PDF output from XML/HTML plus CSS. Prince even supports JavaScript though I don't have any experience with it.
I've got a Java back end in my current application, so for me Flying Saucer works fine for simple reports. I pre-process an HTML template with FreeMarker and then run the result through Flying Saucer. It's got a surprisingly smart rendering engine.
The CSS3 Paged Media spec (well, proposed spec) has all sorts of cool stuff in it but they're almost totally unimplemented in the browsers. Even the CSS2 paged media stuff is only supported half-heartedly.
Speaking of Prince, you might look into DocRaptor. DocRaptor is another HTML to PDF conversion application. It uses Prince XML, and handles CSS better than comparable programs.
It isn't free, but offers a free 30 day trial for all accounts, so there's no harm in trying it out, at least.
DocRaptor
If JavaScript and CSS files were included inside of pages it would cut down the number of http requests and therefore make the page load faster. I feel like I am missing something because it seems like any organization interested in lightning-quick pages would do this. However, I don't recall any sites having tons of CSS and JavaScript into their pages as I look at the source code.
Questions:
What errors are in my statements above?
What are the drawbacks of this approach (shown in the title via psuedocde)?
If the data is in an external file it can be cached and reused on other pages (or the same page, revisited) without having to fetch it over the network again.
You get a minor performance penalty on the first page in exchange for a major performance enhancement on subsequent pages.
Modularity is a major concern:
I can pick and choose which javascript and css files I want per page: otherwise I'd have a ton of css and javascript files that have all the different configurations (which is just messy).
I can also cache a file and hand it to someone else faster
Where you will find an example of this happening is when sites chuck their images together into one png file and then use css to slice up the bits they want for buttons etc.
Another aspect not only for inline css and jscript. When I write code I hate to repeat. It leads to errors is difficult to maintain (update/edit) and a waste of time and space. Printing CSS or jscript once in a file that gets downloaded once is less error prone, easy to maintain and less waste of time and space.
I need some opinions on using PHP to make completely "scalable" websites.. For instance, using viewport resolution and resizing images, applying dynamic css styles..... In my mind doing this just add's to the complexity and should not be done, it should be fixed or fluid using strictly css and no server-side languages to generate layouts based on the device size..
I need some input and maybe some philosophy on why using this approach is not used at all..
Manipulating a web page in this way is the domain of CSS controlled by Javascript (or a library such as JQuery, see CSS docs). You shouldn't be wasting your server's processor cycles when client-side implementations will be far more responsive for the user and allow all the flexibility you require. Changing font size etc can be done almost instantly in the browser without the user having to request another page from your (remote) server, which would result in a slower user experience.
Really, really DON'T
As Andy says it is the domain of CSS.
Trying to adapt a design with PHP will make your code unmaintainable. You should really learn to use CSS efficiently to avoid this kind of hack.
The only reason for which you could use PHP to detect browser and adapt content is mobile browser.
Given the number of the existing User Agent tokens, it'll be almost impossible to make y scalable websites.
I've recently bumped into facelift, an alternative to sIFR and I was wondering if those who have experience with both sIFR and FLIR could shed some light on their experience with FLIR.
For those of you who've not yet read about how FLIR does it, FLIR works by taking the text from targeted elements using JavaScript to then make calls to a PHP app that uses PHP's GD to render and return transparent PNG images that get placed as background for the said element, where the overflow is then set to hidden and padding is applied equal to the elements dimensions to effectively push the text out of view.
This is what I've figured so far:
The good
No flash (+for mobiles)
FLIR won't break the layout
Images range from some 1KB (say one h3 sentence) to 8KB (very very large headline)
Good documentation
Easy to implement
Customizable selectors
Support for jQuery/prototype/scriptaculous/mooTools
FLIR has implemented cache
Browsers cache the images themselves!
The bad
Text can't be selected
Requests are processed from all sources (you need to restrict FLIR yourself to process requests from your domain only)
My main concerns are about how well does it scale, that is, how expensive is it to work with the GD library on a shared host, does anyone have experience with it?; second, what love do search engines garner for sIFR or FLIR implementations knowing that a) text isn't explicitly hidden b) renders only on a JavaScript engine.
Over the long term, sIFR should cache better because rendering is done on the client side, from one single Flash movie. Flash text acts more like browser text than an image, and it's easy to style the text within Flash (different colors, font weights, links, etc). You may also prefer the quality of text rendered in Flash, versus that rendered by the server side image library. Another advantage is that you don't need any server side code.
Google has stated that sIFR is OK, since it's replacing HTML text by the same text, but rendered differently. I'd say the same holds true for FLIR.
I know that with sIFR, and I assume with FLIR that you perform your markup in the same way as usual, but with an extra class tag or similar, so it can find the text to replace. Search engines will still read the markup as regular text so that shouldn't be an issue.
Performance-wise: if you're just using this for headings (and they're not headings which will change each page load), then the caching of the images in browsers, and also presumably on the server's disk should remove any worries about performance. Just make sure you set up your HTTP headers correctly!
since FLIR is IMAGES and sIFR is flash i would imagine that it would be a bit more resource intensive to use sIFR. I havent run any tests but it seems logical.
Search engines search sIFR better than FLIR because some search engines can go into the text of a flash document
I don't know much about sIFR because FLIR worked, and it "felt" better to me than Flash. Just looking at the sIFR 3 beta demo page I noticed that it doesn't seem to react to browser preference text resizing. That is, I increase my font-size in Firefox (ctrl-+) and reload the page, the headings stay the same size.
To those who know sIFR, is this an actual limitation of the script or did they just do the demo page wrong?
If it actually doesn't handle this, I'd call that a major advantage for FLIR, which does work this way. People with impaired vision who don't use screen readers probably don't appreciate that the text doesn't resize to their preference.
That said, from a quick glance at sIFR's API, you should be able to make resized text work in sIFR. I'd consider it a bug to be fixed, not an essential disadvantage of the method.
Woff files is the best solution.
http://www.fontsquirrel.com/tools/webfont-generator