UNIVERSITY OF ENGINEERING AND TECHNOLOGY
VIETNAM NATIONAL UNIVERSITY OF HANOI



STUDENT SCIENTIFIC RESEARCH CONTEST
2012




PROJECT:
EVALUATING PERFORMANCE OF DRUPAL




Name: Vu Quang Son
Class: K53CA
Faculty: Computer Science
Supervisor: Dr. Vo Dinh Hieu







Hanoi, 2012
2

PROJECT SUMMARY

Project: Evaluating performance of Drupal
Research time: 29/01/2012 – 29/03/2012

1. Motivation
My motivation is to research on performance testing for web applications and
then apply to evaluate performance of Drupal – a top open source content management
framework (CMF) nowadays.
2. Main content
In this project, I focus on evaluating performance of the latest Drupal 7 release
at the time of this research (version 7.12 published on February 2
nd
, 2012) by:
- Compare its performance with the latest release of Joomla at the time of this
research (version 2.5.1 published on February 2
nd
, 2012) – another top open source
content management system.
- Compare its performance between default configuration and optimized
configuration
For each evaluation, a summary report will be given based on the result of
testing.
3. Research result
- An overview of performance testing for web applications
- An overview of architecture of Drupal content management framework
- An experimental on Drupal performance with the following parts:
o A comparison between Drupal and Joomla performance
o A comparison between Drupal 7.12 default configuration and optimized

configuration performance
3

Table of contents
I. INTRODUCTION 5
II. PERFORMANCE TESTING FOR WEB APPLICATIONS 7
1. Overview 7
2. Types of performance testing 7
3. Core activities of performance testing 8
III. OVERVIEW OF DRUPAL 9
1. What is Drupal 9
2. Technology stack 9
3. Drupal work flow 9
IV. PERFORMANCE EVALUATION 11
1. Evaluating default Drupal 7.12 performance, a comparison with Joomla 11
1.1. Identify test environment 11
1.2. Plan and design tests 13
1.3. Execute tests 14
1.4. Analyze test results, report 16
2. Evaluating cache and page compression in Drupal 7.12 performance 17
2.1. Identify test environment 17
2.2. Plan and design tests 18
2.3. Execute tests 19
2.4. Analyze test results, report 20
3. Evaluating front-end bandwidth optimization in Drupal 7.12 performance 22
3.1. Back-end and front-end performance 22
3.2. Make fewer HTTP requests 22
3.3. Identify test environment 23
3.4. Plan and design tests 24
3.5. Execute tests 24

3.6. Analyze test results, report 25
V. CONCLUSION 27
VI. REFERENCES 28

4

Table of figure
Figure 1 – Drupal’s technology stack 9
Figure 2 – Drupal’s architecture view 10
Figure 3 – Blank theme website built with Drupal 7.12 11
Figure 4 – Default theme website built with Drupal 7.12 12
Figure 5 – Default theme website built with Joomla 2.5.1 12
Figure 6 – Apache jMeter – HTTP request configuration 14
Figure 7 – Apache jMeter – Thread group configuration 14
Figure 8 – Result for testing Drupal default theme with 10 RPS 15
Figure 9 – Result for testing Drupal default theme with 120 RPS – errors appear 15
Figure 10 – Result of testing average response time with different RPS 16
Figure 11 – Enable cache and Gzip compression in Drupal website 18
Figure 12 – Apache Benchmark result for testing Drupal site non-cached page 19
Figure 13 – Result for testing requests per second 20
Figure 14 – Result for testing bandwidth usage 21
Figure 15 – End user response time of a web page 22
Figure 16 – Enable CSS and JavaScript aggregation in Drupal 23
Figure 17 – Result testing default Drupal site with YSlow – Statistics view 24
Figure 18 – Result testing optimized Drupal site with YSlow – Statistics view 25

List of table
Table 1 – Comparison in file’s weight – Drupal default and optimized site 25
Table 2 – Comparison in number of requests – Drupal default and optimized site 26
Table 3 – Comparison in loading time – Drupal default and optimized site 26


5

I. INTRODUCTION
Nowadays, web sites become an essential part in every aspect of human life
from economy, education, culture to entertainment. We can do a lot of things thank to
the presence of the internet applications that we have on our computer systems. The
importance of web application developments lie in the fact that without their
innovations, internet usage and internet interaction would not have been what it is
today. Therefore, building high quality websites should be considered. Of which high
speed generating and loading page or website performance is a key factor. Why is it? It
is only for a single reason:
Users care about performance!
Web site’s visitors will not be waste their time waiting for page loads
themselves, but they will browse elsewhere when they are forced to wait too long. Fast
web sites are rewarded, slow web sites are punished. Scalable and high performance
web sites get more visitors; have happier visitors and their visitors return more often.
If the revenue of a company is generated through web site, they will want to make sure
that their website performance is as good as possible, because it will reduce the time
required to access information, increase the number of satisfied visitors and maximize
their revenue as well.
Some statistics:
 Amazon: 100 ms of extra load time caused a 1% drop in sales [
1
]
 Yahoo!: 400 ms of extra load time caused a 5-9% drop in full page
traffic (meaning that they leave before the page has finished generating
and loading) [1]
 Google: 500 ms of extra load time caused 20% fewer searches [1]
 Google: trimming page size by 30% resulted in 30% more map requests

[
2
]
Hence, it is clear that even the smallest delay can have disastrous and website
performance is a big problem to care about. However, there is a question can be risen
up: How to evaluate performance of a website accurately. In some cases, the
performance tests overestimated the performance and scalability of the web sites –
leading to embarrassing and costly crashes when the web sites were deployed. In other
cases, they underestimated the capacity and scalability – leading to unnecessary
spending on hardware and infrastructure.
6

The purpose of this research is studying on:
 Key concept of performance testing including load testing, stress testing,
and other types of performance related testing
 An approach for evaluating web sites including all core activities of
performance testing: identifying objectives, designing tests, executing
tests, analyzing results, and reporting.
 Applying the above approach to execute an experimental on performance
of Drupal – the most popular content management framework nowadays
- to discover its speed, capacity and scalability.
Now, why is this important to Drupal – because this research is about
evaluating performance of Drupal in particular? No, because the Drupal experience get
better: evaluating exactly performance of a Drupal website, we can:
 Decide whether using Drupal as our website framework or using other
content management framework instead, such as Joomla or so on.
 In case of using Drupal, know how many users our website can serve
without crashing, how much money we should invest on hardware and
infrastructure for web server.
 Measure the current speed, capacity and scalability of Drupal site and

base on these measurements to improve its performance, both in front-
end and back-end.
More generally, a better performance Drupal would affect many:
 Drupal is increasingly being used for big, high-traffic web sites, thus a
better Drupal performance, a faster Drupal site would affect a lot of
people
 Drupal is still growing in popularity (according to its usage statistics,
which only include web sites with the Update Status module enabled,
there are over 670,000 web sites as of March 4
th
, 2012 [
3
]) and would
therefore affect ever more people.
 Drupal is international, thanks to its internationalization and localization
support, and thanks to that it is used for sites with very geographically
dispersed both in developed and developing countries. A faster
performance Drupal would make a big difference there as well.
7

II. PERFORMANCE TESTING FOR WEB APPLICATIONS
The main task of any testing activity is to collect information in order to help
stakeholders make right decisions related to the overall quality of the application being
tested. Performance testing additionally focus on helping to identify bottlenecks in a
system, tuning a system, establishing a baseline for future testing, and determining
compliance with performance goals and requirements. In addition, the results from
performance testing and analysis can help to estimate the hardware configuration
required to support the application when the productions “go live”.
1. Overview
Performance testing is a type of testing intended to determine or validate the

speed, scalability, and/or stability characteristics of the system or application under a
given workload. Performance is concerned with achieving response times, throughput,
and resource-utilization levels that meet the performance objectives for the project or
product. Performance testing is commonly conducted to accomplish the following:
 Assess production readiness
 Evaluate against performance criterion
 Compare performance characteristics of multiple systems or system
configurations
 Find the source of performance problems
 Support system tuning
 Find throughput levels
2. Types of performance testing
The following are the most common types of performance testing for Web
applications.
Load testing: This type of testing is usually used to understand the behavior of
the system under a specific expected load. This load can be the expected concurrent
number of users performing a specific number of transactions within the set duration.
This test will give out the response times and point towards any bottlenecks in the
application software.
Stress testing: Stress testing is normally used to understand the upper limits of
capacity within the system. This kind of test is done to determine the system's
robustness in terms of extreme load and helps administrators to determine if the
8

system will perform sufficiently if the current load goes well above the expected
maximum.
Endurance testing: This type of testing is usually done to determine if the
system can sustain the continuous expected load. During endurance tests, memory
utilization is monitored to detect potential leaks and to ensure that the throughput
and/or response times after some long period are as good as or better than at the

beginning of the test.
Spike testing: Spike testing is done by suddenly increasing a very large amount
of users or loads and observing the behavior of the system. The goal is to determine
whether performance will suffer, the system will fail, or it will be able to handle
dramatic changes in load.
Configuration testing: This type of testing is created to determine the effects of
configuration changes to the system's components on the system's performance and
behavior. A common example would be experimenting system’s performance with
different methods of tuning and optimization.
3. Core activities of performance testing
There are many approaches used for performance testing. In this research, a
method with following activities is applied:
Activity 1: Identify test environment. Identify the test environment as well as
the tools and resources available for testing. The test environment includes hardware,
software, and network configurations. Having a clear and thorough understanding of
the test environment at the beginning enables more efficient test design and planning
and helps identify testing challenges early in the project.
Activity 2: Plan and design tests. Define test data, determine variability and
how to simulate that variability, identify key scenarios. Combine this information into
one or more strategy to be implemented, executed, and analyzed.
Activity 3: Execute the Test. Run and monitor tests. Validate the tests, test
data, and results collection. Execute validated tests for analysis while monitoring the
test and the test environment.
Activity 4: Analyze Results, Report, and Retest. Review, compare and analyze
the data. Writing report base on result and re-execute test as needed. If all of the
desired information has been collected, the test for that particular scenario on that
particular configuration has been finished.
9

III. OVERVIEW OF DRUPAL

1. What is Drupal
Drupal is a free and open source web content management system (CMS) and
content management framework (CMF). It is used to build web sites ranging from
personal blogs to corporate, political, and government sites including whitehouse.gov
and data.gov.uk. Drupal ships with basic core functionality, and additional
functionality is gained by enabling built-in or third-party modules. Drupal is designed
to be customized, but customization is done by overriding the core or by adding
modules, not by modifying the code in the core. Drupal’s design also successfully
separates content management from content presentation.
2. Technology stack
Drupal’s design goals include both being able to run well on inexpensive web
hosting and being able to scale up to massive distributed sites. The former goal means
using the most popular technology. The operating system is at such a low level in the
stack that Drupal does not care much about it. Drupal runs successfully on any
operating system that supports PHP. Drupal’s technology stack is illustrated in the
following figure:

Figure 1 – Drupal’s technology stack
3. Drupal work flow
The Drupal’s core is responsible for providing the basic functionality that will
be used to support other parts of the system. The core includes code that allows the
10

Drupal system to bootstrap when it receives a request, a library of common functions
frequently used with Drupal, and modules that provide basic functionality
Drupal handles requests from a user through a series of steps. For example, the
Drupal core first bootstraps the application, defines critical variables and frequently
used functions. Next, it loads critical libraries, themes, modules and so on. Finally, it
returns this output to the user's browser. At predefined moments in this step-by-step
process, Drupal executes hooks. In short, it means that Drupal examines some or all of

the currently enabled modules, looking for functions that follow specific, predefined
patterns
Hooks allow modules to “hook into” Drupal’s core. Suppose user logs in,
Drupal fires hook_user_login. It means that any function named according to the
convention module name plus hook name will be called. For example,
comment_user_login() in the comment module, locale_user_login() in the locale
module, node_user_login() in the node module, and any other similarly named
functions will be called.

Figure 2 – Drupal’s architecture view




11

IV. PERFORMANCE EVALUATION
1. Evaluating default Drupal 7.12 performance, a comparison with Joomla
In this section, I built four small web sites with the following features:
 Two web sites built with blank theme, one using Drupal 7.12 and one
using Joomla 2.5.1
 Two web sites built with default theme and enabled the same
functionalities, one using Drupal 7.12 and one using Joomla 2.5.1
The evaluation will focus on the results of testing the response time and amount
of requests per second (RPS) that the server can hold before server crashing. The
results from the evaluations will be compared to get a conclusion of whether Drupal or
Joomla have a better speed, scalability and/or stability. Now, why choosing Joomla for
comparison. Because Drupal and Joomla are currently considered the top two open
source content management systems (CMS) and an exactly comparison between two
latest versions of them will have a big influence on CMS’s users and developers.

1.1. Identify test environment
1.1.1. The test sites
For two blank theme web sites, there isn’t anything on the page except a word
“Home”. The screenshot of blank theme web site built with Drupal 7.12 is as
following. And the one built with Joomla 2.5.1 is similar to it.

Figure 3 – Blank theme website built with Drupal 7.12
For two default theme web sites, some features are enabled and put in the same
place to make them look alike such as login block, search block, main menu and so on.
The images below show how both Drupal and Joomla page was configured:
12


Figure 4 – Default theme website built with Drupal 7.12

Figure 5 – Default theme website built with Joomla 2.5.1
13

1.1.2. The virtual server
In this research, the virtual server configuration is kept the same for all tests.
The virtual server used for hosting these web sites has the following specifications:
- Hardware configuration:
o Intel core 2 Duo @ 2.13GHz running Windows 7 Ultimate 32-bit
o 15GB free disk space, 2GB RAM
- Software configuration: The web server XAMP stack versions are:
o Apache 2.2.17
o PHP 5.3.5
o MySQL 5.0.51a
- Network configuration: LAN connection with a speed of 100Mbps
1.1.3. The testing tool

A testing tool is needed to measure the response time and the amount of traffic
that server can take before user’s requests are queued, failed or the server crashes.
Apache jMeter [
4
] is a great tool to execute test with different request per second
(RPS) values each time while monitoring the server’s health. The RPS value will be
increased until the server cannot take any requests which mean the Apache Server stop
working.
1.2. Plan and design tests
To prepare for tests, a computer has been used to send HTTP requests to the
web server by using Apache jMeter. Figure 7 shows how a HTTP request was
configured:
- Server Name or IP is the IP address of virtual server: 192.168.1.100
- Timeouts connection is set to 50 seconds
- Method call is GET with the option KeepAlive enabled
- Path defines the path to the website. This variable is changed depend on which
website is being tested.
Next step is to define number of virtual users calling HTTP requests per second
which is called a thread group in Apache jMeter. Figure 8 illustrates how a thread
group was defined:
- Number of Threads (users) is the number of virtual users. This number is
increased each time testing by 10
14

- Ramp-Up Period tells jMeter how long to take and run full number of threads
(requests) chosen. This field is set to 1 second
- Loop Count tells jMeter how many times each thread will execute the test. This
field is set to infinite loop.

Figure 6 – Apache jMeter – HTTP request configuration


Figure 7 – Apache jMeter – Thread group configuration
1.3. Execute tests
After finishing configurations, all web sites are tested with different RPS.
Figure 9 shows the graph result for testing Drupal default with 10 requests per second:
15



Figure 8 – Result for testing Drupal default theme with 10 RPS

Figure 9 – Result for testing Drupal default theme with 120 RPS – errors appear
16

Figure 10 illustrates the result for testing Drupal default theme website with 120
requests per second (RPS). As can be seen from the above image that when testing
Drupal default theme website with 120 RPS, the web server stop working and the
result appears errors. It means that Drupal default theme website can only serve up to
110 users visiting per second without server crashing. The result of maximum RPS the
website can serve and the average response time for different RPS are two criteria for
comparison.
1.4. Analyze test results, report
1.4.1. Test result
The following image shows the result of testing average response time with
different RPS for each web site.

Figure 10 – Result of testing average response time with different RPS
1.4.2. Test result analysis
As can be seen from Figure 11 that:
- Joomla default theme website can serve maximum of 80 RPS while Drupal default

theme website can serve up to 110 RPS before Apache Server stop working. It
means that Drupal site has a better scalability than Joomla site.
0
2
4
6
8
10
12
14
16
1
RPS
10
RPS
20
RPS
30
RPS
40
RPS
50
RPS
60
RPS
70
RPS
80
RPS
90

RPS
100
RPS
110
RPS
Joomla blank theme
Joomla default theme
Drupal blank theme
Drupal default theme
Average response time
17

- From 30 RPS going forward, it is clear to see that Joomla default theme website
has a higher average response time than Drupal default theme. It means that Drupal
site has a better speed than Joomla site.
- The more features and functionalities are enabled, the more average response time
will increase. However, there is a big different between the average response time
of Joomla blank theme (with no feature enabled) and default theme (with lots of
features enabled) in contrast with a small different in Drupal. Therefore, Drupal is
more stable than Joomla
2. Evaluating cache and page compression in Drupal 7.12 performance
Both Drupal and Joomla have page cache mechanism that stores dynamically
generated web pages in the database. By caching a web page, Drupal and Joomla
website does not have to re-create the page each time it is requested. Only pages
requested by anonymous visitors, who have not logged on, are cached. Once users
have logged on, caching is disabled for them because the pages are personalized in
various ways. In addition, Drupal and Joomla also support page compression which is
called Gzip. Compressing the page will reduce the document length, save the
bandwidth usage and in some cases serve the page faster.
By default, cache and Gzip for Drupal and Joomla are not enabled. This section

shows a comparison between performance of Drupal and Joomla in three cases: cached
page, non-cached page, and cached page with Gzip. The evaluation will focus on the
document length and the amount of requests per second (RPS) that Drupal and Joomla
website capable of serving. The results from the evaluations will be compared to get a
conclusion of whether Drupal or Joomla have a better performance on cache and Gzip
mechanism.
2.1. Identify test environment
2.1.1. The test site
Default theme website of Drupal 7.12 and Joomla 2.5.1 is used for this
performance testing. The screenshot of two websites are shown in Figure 4 and 5. For
two cases cached page and cached page with Gzip, caching and bandwidth
optimization are enabled from the administration page of both Drupal and Joomla. The
image below shows how caching and Gzip compression are enabled in Drupal. The
configuration for Joomla is similar to Drupal.
18


Figure 11 – Enable cache and Gzip compression in Drupal website
2.1.2. The testing tool
A testing tool is needed to measure the document length and the number of
requests that Drupal and Joomla site is capable of serving per second. Apache HTTP
server benchmarking [
5
] is an excellent tool to execute test with different total number
of requests and different number of concurrent users.
2.2. Plan and design tests
A computer has been used to send HTTP requests to the web server by using
Apache Benchmarking tool. Both Drupal and Joomla website was requested 300 times
with a concurrency of 10. For example, to send 300 requests with a concurrency of 10
to the website www.example.com, the following command is used:

ab –n 300 –c 10 www.example.com/
In which:
o –n requests: is the total number of requests to perform for the testing
o –c concurrency: is the number of multiple requests to perform at a time
To test the impact of compression with Gzip, the command below is used:
ab –n 300 –c 10 –H “Accept-Encoding: gzip;” www.example.com/
In which: -H custom-header: is called to append extra headers to the requests
19

2.3. Execute tests
Both Drupal and Joomla website are tested with a total of 300 requests and a
concurrency of 10. Figure 12 shows the result for testing Drupal website with non-
cached page.

Figure 12 – Apache Benchmark result for testing Drupal site non-cached page
In the above image, there are two numbers that I care about: the document
length and the number of requests per second. According to this image, for Drupal site
with non-cached page, it has a document length of 13920 bytes and it can serve 6.73
requests per second. The test is done similarly with cached page and cached page with
Gzip for both Drupal and Joomla website.
20

2.4. Analyze test results, report
2.4.1. Test result – a comparison of requests per second
The below figure illustrates the number of requests per second that Drupal and
Joomla website can serve in three aspects: no cache; cache and cache with Gzip.

Figure 13 – Result for testing requests per second
2.4.2. Test result analysis – a comparison of requests per second
According to Figure 13, it is clear to be seen that:

- When caching is disabled, Drupal can serve 6.73 RPS while Joomla can serve 5.75
requests per second (RPS). Therefore, Drupal is 17% faster than Joomla.
- When caching is enabled, Drupal can serve up to 62.75 RPS while Joomla can only
serve 9.55 RPS. Hence, Drupal is 557% faster than Joomla.
- Or in other words, Drupal’s cache system improves performance by 832% while
Joomla’s cache system improves performance by only 66%.
- However, it is important to note that Drupal can only serve cached pages for
anonymous visitors who have not logged on the website. Once users have logged
on, caching is disabled for them because the page is personalized in various ways.
Therefore, in practice, Drupal might not be 557% faster than Joomla. It depends on
the ratio of anonymous visitors versus authenticated visitors visiting the website.
6.73
62.75
65.08
5.76
9.55
9.18
0
10
20
30
40
50
60
70
No cache Cache Cache + Gzip
Drupal
Joomla
Requests per second


21

- Finally, when serving cached with Gzip-compressed pages, Drupal becomes
slightly faster - about 3.7% - compared to having to serve non-compressed pages.
Joomla, on the other hand, becomes a little bit slower, about 4%. The reason is that
Drupal’s page cache stores its content directly in a compressed state and it can
serve a page directly from the page cache when the client supports Gzip
compression. Or in other words, Drupal caches the web pages in compressed state
while Joomla caches in uncompressed state. It is still the tradeoff. If the client does
not support Gzip compression, Drupal performance will be impacted because it has
to un-compress the cached compressed web pages for the client.
2.4.3. Test result – a comparison of document length
The following chart shows the difference of bandwidth usage between Drupal
and Joomla in three cases: no cache; cache and cache with Gzip.

Figure 14 – Result for testing bandwidth usage
2.4.4. Test result analysis – a comparison of document length
As can be seen from Figure 14 that:
- The cost of uncompressing or compressing pages is very clear and legible.
Enabling Gzip compression for the page has a significant impact on the document
length and also on the bandwidth usage. Drupal’s compression reduces the
13902 13902
4102
15881
15984
4388
0
2000
4000
6000

8000
10000
12000
14000
16000
18000
No cache Cache Cache + Gzip
Drupal
Joomla
Document length (bytes)

22

bandwidth usage by 239% while Joomla’s compression saves up to 264% of the
bandwidth usage. Hence, Joomla’s compression mechanism is better than Drupal’s.
- However, Drupal always attempts to send compressed pages to the clients while
Joomla does not compress pages unless this option is explicitly turned on.
3. Evaluating front-end bandwidth optimization in Drupal 7.12 performance
3.1. Back-end and front-end performance
When clients visit a web page, the period of time from the request sent until the
page completely loaded and displayed on the browser is called the end user response
time. The majority of this time is not spent at the server for generating the page. The
generating (back-end) and transporting (front-end) of the HTML document is typically
only 10-20% of the end user response time [
6
]. The other 80-90% of the end user
response time is spent on loading the components in the page such as CSS style sheets,
JavaScript, images, movies and so on (front-end only). Figure 15 clarifies this visually:

Figure 15 – End user response time of a web page

3.2. Make fewer HTTP requests
When clients browse a web page, every component in that page produces a
HTTP request and each HTTP request will take time for sending, waiting, connecting,
and receiving response from the server. Hence, the fewer HTTP requests are made, the
more time we will save. Moreover, most of the current browsers can support to receive
(download) at least 4 components in parallel; therefore, fewer HTTP requests of large
10%
90%
End user response time
HTML
Components
23

components are better than many HTTP requests of smaller components. Or in other
words, by combining, aggregating or any other methods to reduce the number of
components on a page will decrease the number of HTTP requests required to render
the page, resulting in faster page loads.
Drupal website contains a lot of JavaScript (JS) and CSS style sheets (CSS) not
only in the core but also in the theme and modules. However, Drupal can gather all the
CSS and JS files to fewer big files through front-end bandwidth optimization support
for CSS and JS. By default, this optimization is not enabled. This section shows a
comparison between performance of a Drupal website before and after enabling CSS
and JS optimization. The evaluation will focus on the total number of HTTP requests,
the total weight of the web page and the page loading time. The results from the
evaluations will be compared to get a conclusion of how much Drupal performance
will improve when enable front-end bandwidth optimization support for CSS and JS.
3.3. Identify test environment
3.3.1. The test site
Default theme website of Drupal 7.12 is used for this performance testing. The
screenshot of the website is illustrated in Figure 4. In case of CSS and JS optimization,

“Aggregate and compress CSS files” and “Aggregate JavaScript files” options are
enabled from the administration page. The image below shows how front-end
bandwidth optimization is applied in Drupal:

Figure 16 – Enable CSS and JavaScript aggregation in Drupal
24

3.3.2. The testing tools
A testing tool is needed to measure the weight, loading time and number of
HTTP requests of a web page. YSlow [
7
] is one of the best tools for measuring these
parameters. It is a Firebug [
8
] extension which is a Firefox plugin. YSlow not only can
summarize the page components but also produce chart with statistics and grade
performance of a page base on various rules.
3.4. Plan and design tests
A computer using Firefox browser with YSlow plugin installed has been used
for testing. To measure the loading time, both default and optimized Drupal website
are requested 10 times to get the average result.
3.5. Execute tests
Figure 17 and 18 shows the results in statistics view for testing default and
optimized css, js Drupal website by using YSlow The loading time, the total number of
HTTP requests and the weight of all components are recorded for comparison.

Figure 17 – Result testing default Drupal site with YSlow – Statistics view
25



Figure 18 – Result testing optimized Drupal site with YSlow – Statistics view
3.6. Analyze test results, report
3.6.1. Test results
Table 1 and 2 illustrate the comparison between default and optimized Drupal
site in file’s weight and number of requests. Table 3 shows the average loading time
for both websites after 10 times of testing.

Default Drupal
(Kbytes)
Optimized CSS, JS Drupal
(Kbytes)
Saving
(Kbytes)
Saving
(%)
HTML/Text
13.7
12.9
0.8
1.3
JavaScript
95.4
32.4
63
101.9
CSS
51.7
9.7
42
68.0

CSS Image
1.6
1.6
0
0
Image
4.1
4.1
0
0
Favicon
1.1
1.1
0
0
Total
167.8
62.2
105.8
171.2
Table 1 – Comparison in file’s weight – Drupal default and optimized site