Current time: 11-01-2020, 12:06 AM Hello There, Guest! (LoginRegister)

Post Reply 
 
Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Test Results not looking good. Need some help please.
12-05-2013, 02:17 AM (This post was last modified: 12-05-2013 03:12 AM by iSpeedLink.com.)
Post: #10
RE: Test Results not looking good. Need some help please.
(12-04-2013 03:19 AM)pmeenan Wrote:  @iSpeed,The slow start render has nothing to do with the CSS location -
If you do not believe me, maybe you will believe Google:
From Google's Web Performance Best Practices
"Browsers block on external CSS files before painting content to the screen. This incurs additional network latency and increases the time it takes to display content to the screen."

How does the page get rendered without the CSS?

When subsequent CSS links are encounter by the Browser the rendering has to re-start. Look at the waterfalls and the location of the last CSS and the Start Rendering. Locating the CSS at the top of the <HEAD> is a fact. Not my opinion.

Think about it. First the C in CSS, is CASCADING. means child selector attributes will inherit attributes from form parent selectors. When the parent or child is in the subsequent CSS file will that not have an effect on page rendering?

Secondly the order in which the STYLE attributes are defined sets precedence. Subsequent attributes override the prior.

The Browser must complete the DOM database tables to be able to render the page. When parsing the CSS and the Browser encounters new CSS the Browser could instead examine to see if and how this change will affect the rendering already done. This would add some very complex code and slow the process, it is then likely the Browser will determine that the best approach to deal with the new CSS changes is to start over.

Or they could simply without need for additional complex code just start over. They can then, as they have, publicize the rule about putting the CSS first so the Browser does not have to re-start rendering.

(12-04-2013 03:19 AM)pmeenan Wrote:  @iSpeed,- the main issue is that there are so many separate css and js files that are being loaded individually (though they are all cacheable so it's mostly a first visit hit).

There will be NO second cached visit when the user clicks the Back button rather than wait for the first page load.

The first and foremost is the fist page view in order to get in to the cache. When the user clicks the Back button rather than wait for the first page load the cache does not get loaded.

Furthermore there will be less first loads because Google is very careful to monitor the time you click on a link and when you return from the site. Every time someone bounces from a Search Link the page is lowered in the ranking for that search term. With lower ranking there will be fewer referrals from Google. With no Google referral there will consequently be no need for a cached second view.

The Google bot is only concerned about first page views. Google's job is to refer good quality links to their users. It is in Google's best interest to filter out pages that load slow. Most Google users are visiting site for the first time. Because Google knows (as they have published) how many will abandon a site with slow a page load. Again, with no Google referral there will consequently be no first view or a need for a cached second view.

Google has also published they use page load speed in their ranking metrics. The even are so concerned with this metric they have gotten involved with a project that ranks Web Page Speed. Maybe you have heard of it? PageSpeed Insights. Slow pages are ranked lower and get fewer first views and no cached second views. Again, with no Google referral there will consequently be no first view or a need for a cached second view.

(12-04-2013 03:19 AM)pmeenan Wrote:  Charlie, the redirect looks like it is being done by the application rather than the web server. You should be able to create a simple .htaccess rule that will do the redirect directly (bonus points for making it a cacheable 301 redirect) which would improve any cases where the users hit a redirect.

Where is he going to redirect to? If there were a better page to load first, wouldn't it be better to make that page the index page rather than use a redirect?

Would it not be much better to solve the problem rather than use a time consuming, albeit small, redirect?

Finding the PHP redirect (it is a PHP redirect as evidenced by the header) is a piece of cake using a quick and simple text search of the PHP files for the redirect header() command.

There may be a reason for the redirect. It is possible there is a authentication or initialization process that must be run for an online app to run.

If it's a clandestine hi-jacking it would be wise to find the culprit. It could be a devious Web Developer.

(12-04-2013 03:19 AM)pmeenan Wrote:  Charlie,
you may have to look at adding caching to the application layer itself (depending on what platform it is built on there may be out-of-the-box solutions available).
Caching of dynamic pages adds another level of complexity and another point of failure. Would it not be better to eliminate the need for the caching?

PHP is very capable of doing a better job of transmitting the HTML than a caching solution.

First of all PHP can specify header parameters more dynamically than Apache. PHP can override the default output buffering and send the <HEAD> before the output buffer has enough bytes to trigger early transmission.

Would it not be better to address the underlying PHP problem? In many cases it is just a simple matter of adding a flush() command in the appropriate places.

For Word Press, especially free WP Themes, it is a simple matter of correcting the PHP code. For example WP Themes typically use context switching between HTML and PHP. Throughout the code WP uses <?php $variable ?> in HTML output mode. Each time this happens it requires a time consuming context switch.

The correct way is to keep the mode in PHP output and use Heredoc string quoting and inserting a flush() whenever appropriate.

Most designers process their SQL Queries for dynamic content before sending any HTML.

I will transmit as much of the page as possible. Usually at least the <HEAD> and page HTML header. I will halt the output, flush the buffer, process the SQL query, format the query results storing the resulting HTML in the next output buffer and flush this buffer before the server has completed transmitting the previous buffer.
Find all posts by this user
Quote this message in a reply
Post Reply 


Messages In This Thread
RE: Test Results not looking good. Need some help please. - iSpeedLink.com - 12-05-2013 02:17 AM

Forum Jump:


User(s) browsing this thread: 1 Guest(s)