O SlideShare utiliza cookies para otimizar a funcionalidade e o desempenho do site, assim como para apresentar publicidade mais relevante aos nossos usuários. Se você continuar a navegar o site, você aceita o uso de cookies. Leia nosso Contrato do Usuário e nossa Política de Privacidade.
O SlideShare utiliza cookies para otimizar a funcionalidade e o desempenho do site, assim como para apresentar publicidade mais relevante aos nossos usuários. Se você continuar a utilizar o site, você aceita o uso de cookies. Leia nossa Política de Privacidade e nosso Contrato do Usuário para obter mais detalhes.
Do you know how many third-party scripts your pages are currently running? And do you know how many of those scripts are affecting your site's performance — either by slowing down page rendering or by potentially blocking the entire page?
If you don't know the answer to these questions, you're not alone. The rampant proliferation of third-party scripts makes them difficult to manage and control. In this presentation, you'll walk through a process for testing the scripts on your pages to see which ones represent a SPOF. We'll also review an 11-step plan for bullet-proofing your site against third-party failure.
For more on web performance and application delivery, please visit: http://blog.radware.com/applicationdelivery/applicationaccelerationoptimization/
• Identify all third-party scripts
• Know which pages they’re on
• Find out what performance best
practices, if any, each script uses
(e.g., deferral, async loading)
• Read the SLA for each provider (if they
Blackhole test results fall into one of three groups:
1. SPOF page loads SLOWER than original page
Fix: Deferral or async script
2. SPOF page loads FASTER than original page
Fix: Talk to provider about script hosting
3. SPOF page times out.
Fix: Same as #1
3. Before you add a new script, research
• Response time and time to last byte
• RT and TTLB from multiple locations
• Average monthly downtime
• Do they use a CDN?
• If so, where are their caches located?
4. Read the provider’s
service level agreement.
An ideal third-party SLA should:
• Express monthly annual uptime guarantee as a percentage
(ideally, as close to 100% as possible)
• Explain how performance will be monitored and reported
• Describe the process for reimbursing site owners (if site owners
are paying for the service provided by the script) if uptime drops
below the SLA guarantee